（译）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复制有关。它是一个可以动态修改的变量。默认为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的记录。

第二种方法也需要重新启动数据库。

译者注：
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='IDEMPOTENT'只支持row模式的binlog，不支持statement或者mixed模式的binlog

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模式下的复制，该模式下的复制可以自己测试。

posted on 2023-12-12 20:22 MSSQL123 阅读(375) 评论(0) 编辑收藏举报

刷新页面返回顶部

专注，勤学，慎思。戒骄戒躁，谦虚谨慎

导航