前言
在复制中，有时会因为复制报错，而中断复制。通常是因为一个SQL语句在主库执行时是正常的，但同步到从库时，因为各种原因，找不到对应的数据，造成执行SQL失败，报出复制错误。下面主要写了几个常见的错误。
复制中断的情况和处理
复制中断的情况：
- 1062错误：在写入数据使，从库已存在了。多出现自增长ID已存在。
- 1032错误：从库出现少数据，update、delete时，找不到相应的记录。
- 其他：DDL操作时报错
对这些情况的处理：
- 遇到该问题，要想到要怎样满足复制，而不是跳过该事务;不建议跳过错误，遇到错误应该修正过来，再连接主库复制，否则从库的数据会越来越不一致!
- 手工修复操作有些慢，可以针对1062和1032错误，写一个自动化监控改正脚本。
- 注意：若经常数据不一致，选择业务低峰期，检验一次数据(pt-table-checksum)，查看是否数据一致，若检查出太多的数据不一致，该从库就不可再用了，再创建一个从库!
常见的复制错误
【错误码-1062】
处理操作：
- 处理这种情况，需要和业务协商，或在公司内形成一个规定，遇到这种情况要怎样做(在从库将这条重复数据删除还是补充到主库)。
- 通常，在从库删除该条数据，让复制继续进行。
- 使用pt-slave-restart来修复问题，它会会跳过错误，建议先处理错误，才可以保证数据的一致性
具体操作：
- 定位到该事物
- 传统复制：Exec_Master_Log_Pos 与 last_error中的end_log_pos 中间的事务
- GTID复制：executed_gtid_set : xxxxx:1-5 ，即第6个事务报错了。
- master：mysqlbinlog -vv --base64-output=decode-rows --start-position ……
- 在slave上删除该条数据，然后连接复制
- > set sql_log_bin=0; # 先禁止当前会话的操作记录写到binlog
- > delete from xn_db.t_order_produce where id=35197;
- > set sql_log_bin=1; # 恢复正常
- > start slave sql_thread; # 启动SQL线程
【错误码-1032】
1032错误 分为： update错误 和 delete错误。
update 处理操作：
- 在主库上获取出来主键的值(不需要具体恢复出来)，只要满足SQL执行成功即可。
update 具体操作：
- 定位到该事物
- 传统复制：Exec_Master_Log_Pos 与 last_error中的end_log_pos 中间的事务
- GTID复制：executed_gtid_set : xxxxx:1-5 ，即第6个事务报错了。
- master：mysqlbinlog -vv --base64-output=decode-rows --start-position ……
- 将没有的数据创建出来，只符合错误事务执行成功即可
- > set sql_log_bin=0;
- > insert into xn_db.t_mes(id) values(35592);
- > set sql_log_bin=1;
- > start slave sql_thread;
delete 处理操作：
- 由于从库没有该数据，致使删除失败，可以跳过该错误，因为跳过该删除事务相当于不执行该delete语句，和在从库上没执行之前是一样的，那些数据都不会存在于从库中。
delete 具体操作：
- 传统复制：
- > stop slave;
- > set global sql_slave_skip_counter=1; # 跳过一个事务
- > start slave;
- GTID复制：
- > stop slave;
- > set gtid_net='xxxxx:6' # 跳过报错事务6
- > begin;commit; # 执行一个空事务，即GTID为6的事务
- > set gtid_next='AUTOMATIC';
- > start salve;
