526互联

MySQL中的slave_exec_mode 参数详解（MySQL从节点复制错误处理时，sql_slave_skip_counter VS slave-skip-errors VS slave_exec_mode）（译）

发布时间 2023-12-12 20:25:37作者: MSSQL123
 
 
今天我偶然看到了参数slave_exec_mode。从手册中的描述可以看出，该参数与MySQL复制有关。它是一个可以动态修改的变量。默认为STRICT mode(严格模式)，可选值为IDEMPOTENT mode(幂等模式)。
设置为IDEMPOTENT模式可以防止从库出现1032(从库上不存在的键)和1062(需要重复键、主键或唯一键)的错误。该模式只在ROW binlog模式下生效，在STATEMENT 模式的binlog模式中无效。
幂等模式主要用于多主复制和NDB CLUSTER，其他情况不建议使用。从上面的介绍，这个参数让库跳过指定的错误，那么问题就来了:
1:与sql_slave_skip_counter相比，有什么优势?
2:与slave-skip-errors = N相比，有什么优势?
针对这两个问题，本文将进行相关的检验和解释。
 

环境:

MySQL版本:Percona MySQL 5.7
binlog模式:ROW，未开启GTID

测试case:

① 1062 Error: Could not execute...event on table db.x; Duplicate entry'xx' for key'PRIMARY', Error_code: 1062;

测试表在主从环境中的表结构以及数据如下：
CREATE TABLE `x` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8
Table record on master and slave:
M:
select * from x;
+----+
| id |
+----+
| 2 |
| 3 |
+----+
2 rows in set (0.01 sec)
S:
select * from x;
+----+
| id |
+----+
| 1 |
| 2 |
| 3 |
+----+
3 rows in set (0.00 sec)
主从上的表记录本来不一致，主从上没有id=1的记录。
此时，上面的slave_exec_mode是默认的严格模式:
查看slave_exec_mode变量的值
show variables like'slave_exec_mode';
+-----------------+--------+
| Variable_name | Value |
+-----------------+--------+
| slave_exec_mode | STRICT |
+-----------------+--------+
1 row in set (0.00 sec)
主节点binlog日志的格式:
show variables like'binlog_format'; 
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW |
+---------------+-------+
1 row in set (0.00 sec)
在主节点上执行如下sql:
insert into x values(1),(4),(5);
Query OK, 3 rows affected (0.00 sec)
Records: 3 Duplicates: 0 Warnings: 0
由于从节点上已经存在一条Id=1的数据，此时主从复制报1062错误
Last_SQL_Errno: 1062
Last_SQL_Error: Could not execute Write_rows event on table dba_test.x; Duplicate entry '1' for key'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin-3306.000006, end_log_pos 7124
当发生这种错误时，一贯做法是设置：sql_slave_skip_counter=N.
1，设置 global sql_slave_skip_counter=N ， N 意味着跳过N个事件
2，最好记住当N设置为1时，其结果相当于是将跳过下一个事务。
3，在跳过第n个事件之后，如果该位置恰好落在一个事务中，则将跳过整个事务
4，插入/更新/删除不一定只对应一个事件，这是由引擎和日志格式决定的
sql_slave_skip_counter的单位为“event”。很多人认为这个参数的单位是“事务”，但实际上是错误的，因为一个事务包含多个事件，跳过N可能仍然在同一个事务中。
对于上面的1062错误，将N设置为1到4具有相同的效果，跳过一个事务。因为执行的SQL生成4个事件:
show binlog events in'mysql-bin-3306.000006' from 6950;
+-----------------------+------+------------+----- ------+-------------+----------------------------- ----+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+-----------------------+------+------------+----- ------+-------------+----------------------------- ----+
| mysql-bin-3306.000006 | 6950 | Query | 169 | 7026 | BEGIN |
| mysql-bin-3306.000006 | 7026 | Table_map | 169 | 7074 | table_id: 707 (dba_test.x) |
| mysql-bin-3306.000006 | 7074 | Write_rows | 169 | 7124 | table_id: 707 flags: STMT_END_F |
| mysql-bin-3306.000006 | 7124 | Xid | 169 | 7155 | COMMIT/* xid=74803 */|
+-----------------------+------+------------+----- ------+-------------+----------------------------- ----+
4 rows in set (0.00 sec)
因此处理这种从节点复制报错的方法是：

1: skip_slavesql_slave_skip_counter

stop slave; 
Query OK, 0 rows affected (0.00 sec)
set global sql_slave_skip_counter=[1-4];
Query OK, 0 rows affected (0.00 sec)
start slave;
Query OK, 0 rows affected (0.00 sec)

2: Specify slave-skip-errors=1062 in the configuration file (restart required)

这两种方法可以将复制恢复到正常状态，但会使主从数据不一致(请谨慎使用)，从而使从数据库丢失id=4和5的记录。
第二种方法也需要重新启动数据库。
 

slave_exec_mode

这时本文中介绍的slave_exec_mode参数就会派上用场了。在从库上设置此参数:
set global slave_exec_mode='IDEMPOTENT';
Query OK, 0 rows affected (0.00 sec)
stop slave; 
Query OK, 0 rows affected (0.00 sec)
start slave;
Query OK, 0 rows affected (0.00 sec)
同样地，在master上执行:
insert into x values(1),(4),(5);
惊喜地发现主从数据已经同步，并且没有复制异常:
M:
select * from x; +----+
| id |
+----+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+----+
5 rows in set (0.00 sec)
S:
select * from x; +----+
| id |
+----+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+----+
5 rows in set (0.01 sec)
上面的测试可以看到，在将参数设置为slave_exec_mode='IDEMPOTENT'之后，可以跳过一个错误的事件。

② Error 1032: Could not execute...event on table db.x; Can't find record in'x', Error_code: 1032;

由于采用ROW模式复制，对数据一致性有严格的要求
测试表在主从环境中的表结构以及数据如下：
CREATE TABLE `x` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8
Table record on master and slave:
M:
select * from x; +----+
| id |
+----+
| 1 |
| 2 |
| 3 |
+----+
3 rows in set (0.00 sec)
S:
select * from x;
+----+
| id |
+----+
| 1 |
| 3 |
+----+
2 rows in set (0.00 sec)
主从上的表记录本来是不一致的，上面没有id=2的记录。此时，上面的slave_exec_mode是默认的STRICT 模式:
show variables like'slave_exec_mode';
+-----------------+--------+
| Variable_name | Value |
+-----------------+--------+
| slave_exec_mode | STRICT |
+-----------------+--------+
1 row in set (0.00 sec) 
The binlog mode on M is:
show variables like'binlog_format'; 
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW |
+---------------+-------+
1 row in set (0.00 sec)

Execute on M:
BEGIN;
INSERT INTO x SELECT 4;
DELETE FROM x WHERE id = 2;
INSERT INTO x SELECT 5;
COMMIT;
Because there is no record with id=2 from the above, at this time, the copy of from has reported an error of 1032:
Last_SQL_Errno: 1032
Last_SQL_Error: Could not execute Delete_rows event on table dba_test.x; Can't find record in'x', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin-3306.000006, end_log_pos 12102
同样，上述测试中的两种方法可以使副本正常，但数据也会丢失。丢失id=4和5的记录，在从库上继续设置该参数:
set global slave_exec_mode='IDEMPOTENT';
Query OK, 0 rows affected (0.00 sec)
stop slave; Query OK, 0 rows affected (0.00 sec)
start slave;
Query OK, 0 rows affected (0.00 sec)
Perform the same operation on M:
BEGIN;
INSERT INTO x SELECT 4;
DELETE FROM x WHERE id = 2;
INSERT INTO x SELECT 5;
COMMIT;
您还可以惊喜地发现主从数据是同步的，并且没有复制异常。
注意:slave_exec_mode='IDEMPOTENT'对于DDL操作不能是幂等的，并且对于由不同字段长度引起的错误也不能是幂等的，例如将从库表的id字段类型int更改为bigint。
（译者注：设置slave_exec_mode='IDEMPOTENT' 模式无法解决DDL类型的错误，只能解决从节点上应用主节点binlog时的主键冲突或者无主键错误）
它只能在binlog_format为ROW的模式下使用，并且只能在1032和1062的幂等模式下使用。
 

总结

对于上面的测试总结，对于slave_exec_mode参数，它可以跳过1062和1032个错误，并且不会影响同一事务中的正常数据执行。如果它是由多个sql组成的事务，则可以跳过相关事件。
查看这个参数是非常好的，但是手册指出不建议在正常的复制环境中启用它。对于NDB以外的存储引擎，只有在确定可以安全地忽略重复键错误和无键错误时，才应该使用IDEMPOTENT模式。
该参数是专门为NBD集群设计的。NBD集群模式下，该参数只能设置为“IDEMPOTENT mode”。因此，您必须根据自己的应用场景来决定。
在正常情况下，主从是相同的，任何错误都会被报告。但是，在执行特殊处理时可以暂时打开它。
另外，sql_slave_skip_counter不支持GTID模式下的复制，该模式下的复制可以自己测试。