MySQL主从 常见的错误及解决方案

一、错误日志解析：

(1) 【ERROR】1452:无法在外键的表插入参考主键没有的数据

1452:无法在外键的表插入或更新参考主键没有的数据。由于item_discovery.itemid字段(外键)参考了items.itemid字段(主键)，当要在item_discovery表插数据时，如果items表的主键没有对应的数据，则无法插入，报1452错误。此时可以检查参考的表的主键是否有主库对应的数据，如果有，则插入参考的表相应的数据，再开启复制恢复SQL线程。

(2) 【ERROR】1032:删除或更新数据，从库找不到记录

1032:删除或更新从库的数据，从库找不到记录。此时，主库的数据是比从库新的，可以采取从库添加相同的数据在开启复制恢复SQL线程。

(3) 【ERROR】1062:从库插入数据，发生唯一性冲突

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检查数据一致性。

检查完后可以在从库执行这条语句查看有无数据不一致表:

针对核心表，可以定制自动数据校验脚本，每周进行数据校验，但必须要在业务低谷进行校验哦！

————————————————————

推荐阅读：

【干货】Linux监控 sar命令解析

【干货】Linux Shell常用经典脚本收藏

教你分分钟搞定Python之Flask框架

网页加载性能调优