前言

————

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