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