主从复制模式下跳过错误

今天我们主要看主从模式下,几种跳过错误的方法,跳过事务,还是跳过event?这个在之前其实我们一直都是忽略的,这在我们维护主从过程中,很容易就导致主从数据更大的不一致。
测试机器5.7.18 主从 gtid 开启
主库数据
主从复制模式下跳过错误
从库数据
主从复制模式下跳过错误
很明显主从数据有一个不一直的地方,从库少了一条(28,2) 的数据。这个时候主库开启以下事务:
主从复制模式下跳过错误
这必然导致从库出现错误,报1032错误,如下所示:
MySQL> show slave status\G;
1. row
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.56
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000023
Read_Master_Log_Pos: 1928
Relay_Log_File: hadoop2-relay-bin.000012
Relay_Log_Pos: 1595
Relay_Master_Log_File: mysql-bin.000023
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1032
Last_Error: Could not execute Delete_rows event on table yhtest1.yhtest; Can't find record in 'yhtest', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000023, end_log_pos 1812
Skip_Counter: 0
Exec_Master_Log_Pos: 1502
Relay_Log_Space: 2384
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1032
Last_SQL_Error: Could not execute Delete_rows event on table yhtest1.yhtest; Can't find record in 'yhtest', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000023, end_log_pos 1812
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: ab8c3ec3-b588-11e7-a769-000c29c57be6
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 171130 23:55:18
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: ab8c3ec3-b588-11e7-a769-000c29c57be6:96-101
Executed_Gtid_Set: ab8c3ec3-b588-11e7-a769-000c29c57be6:1:77-100,
b6ddfda0-d8bc-4272-a58f-4ea75acbbc79:1-22:1000012-1000013:2000012-2000013,
d24c1c76-b4ef-11e7-969a-000c29a75f68:1-17
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.01 sec)

成都创新互联坚持“要么做到,要么别承诺”的工作理念,服务领域包括:网站设计制作、做网站、企业官网、英文网站、手机端网站、网站推广等服务,满足客户于互联网时代的罗平网站设计、移动媒体设计的需求,帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴!

解决方法:
方法1
5.7下,由于开启了GTID ,不能通过参数sql_slave_skip_counter=N 跳过错误,但是我们可以通过在从库执行空事物的方法,跳过该错误,但要注意,这样跳过的是一个事物。
从以上报错信息中,我们很容易看出目前执行位置在: ab8c3ec3-b588-11e7-a769-000c29c57be6:1:77-100 也就是报错位置在: ab8c3ec3-b588-11e7-a769-000c29c57be6:1:77-101
操作如下:
主从复制模式下跳过错误
这个时候,我们再次show slave status\G 看到主从已经恢复正常,但是我们再对比数据,发现我们刚才主库的三个event 在同一个事件中,被我们全部跳过了,也就是两个插入数据也没有在从库执行!
主库数据:
主从复制模式下跳过错误
从库数据:
主从复制模式下跳过错误

方法2
如果我们觉得以上方法步骤比较多,还可以借住与pt-slave-restart 来进行主从错误跳过,跳过方法如下:
主从复制模式下跳过错误
这个同样可以达到跳过主从错误的目的!但是其跳过的单位也是事务,同样也会导致主库所做的两个插入没有在从库执行!
方法3
利用slave_exec_mode参数来处理主从中遇到的错误,操作步骤如下:

stop slave;
set global slave_exec_mode='IDEMPOTENT'; 幂等模式 (默认是STRICT严格模式)
start slave;
查看主从数据
主从复制模式下跳过错误
发现一致了,也就是说在调整参数slave_exec_mode后,我们跳过的delete 错误,但是两个插入操作任然是执行的,同时,查看错误日志,我们发现记录如下:
主从复制模式下跳过错误
方法4
利用参数slave_skip_errors跳过错误,操作方法如下,在配置文件中添加slave_skip_errors=1062,1032 等,重启数据库,启动slave ,也会发现测试结果和方法3一致。但是 slave_skip_errors 不支持动态修改!
方法5
从库1032时,我们直接去主库找到对应的记录,插入到从库当中,restart salve, 1062 时 我们直接在从库中备份删除掉冲突记录即可。

这里稍微提一下:mariadb 的Gtid 错误,我们可以采用参数sql_slave_skip_counter=N直接跳过,但是,却不支持使用pt-slave-restart 跳过错误,而且mariadb 的Gtid 和官方不通用,实现原理相同,实现方法缺不同,所以我们也不能用这两个版本之间搭建gtid主从。


新闻名称:主从复制模式下跳过错误
当前URL:http://scyanting.com/article/jjgici.html