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

just do it

导航

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

 
 
今天我偶然看到了参数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  阅读(160)  评论(0编辑  收藏  举报