主从复制模式下跳过错误

原创

雪隐千寻 2017-11-30 17:28:00 博主文章分类：mysql ©著作权

©著作权归作者所有：来自51CTO博客作者雪隐千寻的原创作品，请联系作者获取转载授权，否则将追究法律责任

今天我们主要看主从模式下，几种跳过错误的方法，跳过事务，还是跳过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主从。