共计 2253 个字符，预计需要花费 6 分钟才能阅读完成。
一、问题描述
主从复制错误一直是 MySQL DBA 一直填不完的坑，如鲠在喉，也有人说 MySQL 主从复制不稳定等等，其实 MySQL 复制比我们想象中要坚强得多，而绝大部分 DBA 却认为只要跳过错误继续复制就好啦，接下来不发生错误就好了，其实跳过错误就会有数据不一致的风险，数据不一致可能还会越来越严重，而我就复制错误中反复出现的 1045、1032 和 1062 错误引起的数据库主从不一致的的现象进行深入分析及给出一套完善的解决方案。
(1)【ERROR】1452: 无法在外键的表插入参考主键没有的数据
(2)【ERROR】1032: 删除或更新数据，从库找不到记录
(3)【ERROR】1062: 从库插入数据，发生唯一性冲突
二、原因分析
【ERROR】1452: 无法在外键的表插入或更新参考主键没有的数 据。由于 item_discovery.itemid 字段 (外键) 参考了 items.itemid 字段(主键)，当要在 item_discovery 表插数据时，如果 items 表的主键没有对应的数据，则无法插入，报 1452 错误。此时可以检查参考的表的主键是否有主库对应的数据，如果有，则插入参考的表相应的数据，再开启复制恢复 SQL 线程。
【ERROR】1032: 删除或更新从库的数据，从库找不到记录。此时，主库的数据是比从库新的，可以采取从库添加相同的数据在开启复制恢复 SQL 线程。
【ERROR】1062: 从库插入数据，发生唯一性冲突。此时从库已经有相同主键的数据，如果再插入相同主键值的数据则会报错。可以查看主库的改行数据与从库的要插入数据是否一致，如一致则跳过错误，恢复 SQL 线程，如不一致，则以主库为准，将从库的该行记录删除，再开启复制。
如果当前高可用架构为 Master-Master，则以下均在从库的操作都必须 set sql_log_bin=0，避免从库执行的语句同步到主库（恢复时以主库的数据为准）。
三、标准化处理方案
（旨在落成标准化处理方案）
1.临时解决方案（业务运行期间不适宜使用数据对比和修复工具）
【ERROR】1452:
普通主从复制环境
从库：
主库：
查看主库在出错的相应位置的执行语句，可通过 SQL 得出当时 insert 或者 update 的对应的主键值。
查询 item_discovery 的外键约束 c_item_discovery_1 参考的表 items 对应主键值的数据行。
从库：
在 items 表插入主库查询出来的数据。
基于 GTID 复制环境
与普通主从复制环境处理方式相同。
【ERROR】1032:
发生 1032 可能是 delete 或者 update 时从库没有对应数据行，可以分两种情况处理：
（1）如果是 Could not execute Delete_rows，则可以直接跳过错误
普通主从复制环境
从库：
基于 GTID 复制环境
从库：
找出复制出错时的 executed_Gtid_Set，若出现多个，则选择跟 Master_uuid 相同的那一条。
（2）如果是 Could not execute Update_rows，则需要在二进制日志找出出错位置的 SQL，再找出该表在主库的对应的数据行，然后直接在从库插入这条数据，开启 SQL 线程恢复。
普通主从复制环境
从库：
主库：
查看主库在出错的相应位置的执行语句，可通过 SQL 得出当时 update 的对应的主键值。
查询 item_discovery 的对应主键值的数据行。
从库：
在 items 表插入主库查询出来的数据。
基于 GTID 复制环境
与普通主从复制环境处理方式相同。
【ERROR】1062:
普通主从复制环境
从库：
主库：
查看主库在出错的相应位置的执行语句，可通过 SQL 得出当时 insert 的对应的主键值。
查询 trends_uint 表对应主键值的数据行。
从库：
在 trends_uint 表删除主库查询出来的数据。
基于 GTID 复制环境
与普通主从复制环境处理方式相同。
2.彻底解决方案
使用 pt-table-checksum 和 pt-table-sync 彻底修复数据不一致。
注意：使用 pt 工具包首先要安装 pt 工具包和安装 perl 模块。
(1) 从库停止复制
(2) 在主库创建校验信息表
(3) 在主库用 pt-table-checksum 校验主从数据一致性
在从库执行以下语句，查看 Last_Error，发现数据不一致的表：
然后返回操作系统执行以下命令：
该命令可以查看该表是否发生数据不一致情况，若有，则使用 pt-table-sync 修复。
(4) 在主库用 pt-table-sync 打印出修复不一致数据的 SQL(如果有外键约束，修复数据应先从外键参考的字段所属表开始修复)，后将修复语句在从库执行。
四、优化建议
在复制由于 1045、1032、1062 的原因中断后，应使用三.1 的临时解决方案，恢复复制后再在业务低谷使用 pt-check-sum 检查数据一致性。
检查完后可以在从库执行这条语句查看有无数据不一致表:
针对核心表，可以定制自动数据校验脚本，每周进行数据校验，但必须要在业务低谷进行校验哦！
本文永久更新链接地址：http://www.linuxidc.com/Linux/2017-02/141059.htm
