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

原文地址：https://www.soughttech.com/front/article/7159/viewArticle今天我偶然看到了参数slave_exec_mode。从手册中的描述可以看出，该参数与MySQL复制有关。它是一个可以动态修改的变量。默认为STRICTmode(严格模式)，可选值为IDEMPOTENTmode(幂等模式)。设置为IDEMPOTENT模式可以防止从库出现1032(从库上不存在的键)和1062(需要重复键、主键或唯一键)的错误。该模式只在ROW binlog模式下生效，在STATEMENT 模式的binlog模式中无效。幂等模式主要用于多主复制和NDBCLUSTER，其他情况不建议使用。从上面的介绍，这个参数让库跳过指定的错误，那么问题就来了:1:与sql_slave_skip_counter相比，有什么优势?2:与slave-skip-errors=N相比，有什么优势?针对这两个问题，本文将进行相关的检验和解释。环境:MySQL版本:PerconaMySQL5.7binlog模式:ROW，未开启GTID测试case:①1062Error:Couldnotexecute…eventontabledb.x;Duplicateentry’xx’forkey’PRIMARY’,Error_code:1062;测试表在主从环境中的表结构以及数据如下：

CREATE TABLE `x` ( `id` int(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8Table 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: 1062Last_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，设置globalsql_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:Specifyslave-skip-errors=1062intheconfigurationfile(restartrequired)这两种方法可以将复制恢复到正常状态，但会使主从数据不一致(请谨慎使用)，从而使从数据库丢失id=4和5的记录。第二种方法也需要重新启动数据库。译者注：
sql_slave_skip_counter：该参数不支持GTID模式的复制，类似于slave-skip-errors，会自动跳过出错的event而非事务
slave-skip-errors：在配置文件中设置slave-skip-errors=1062，1032或者直接设置slave-skip-errors= all，需要重启服务，并且在遇到相对应的错误时，从节点会自动跳过整个事务并且不会记录任何错误信息。slave_exec_mode：相对slave_exec_mode=’IDEMPOTENT’来说，设置slave_exec_mode=’IDEMPOTENT’;之后会自动跳过错误的event而非整个事务，同时会记录将自动跳过的event记录到errorlog中。

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’之后，可以跳过一个错误的事件。②Error1032:Couldnotexecute…eventontabledb.x;Can’tfindrecordin’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=utf8Table 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: 1032Last_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集群模式下，该参数只能设置为“IDEMPOTENTmode”。因此，您必须根据自己的应用场景来决定。在正常情况下，主从是相同的，任何错误都会被报告。但是，在执行特殊处理时可以暂时打开它。另外，sql_slave_skip_counter不支持GTID模式下的复制，该模式下的复制可以自己测试。