前言
————
在复制中，有时会因为复制报错，而中断复制。通常是因为一个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';