线上Slave报1062的案例

共计 2038 个字符，预计需要花费 6 分钟才能阅读完成。

最近经常线上的 Slave 老报 1062 的错误，蛋碎一地，幸好 Slave 暂时没有用到业务上，也就是说没有做读写分离，所以 Slave 有问题，影响也不大，但每隔一阵子就报 1062 主键冲突的错误，让我好纠结，如果不解决的话，我都不敢上 Atlas，所以一直在排查到底是什么引起的。虽然大家都知道当 Master 插入的数据所包含的主键或者唯一键在 Slave 上已经存在的时候，就会报 Last_Errno: 1062，主从同步就断开了。但是奇怪的是每次报 1062 的时候，Slave 上的数据都和 Master 想插入的数据一样的，这足以排除人为手动插入数据的可能。

排查过程：

    1、如果经常出现 1062 错误的时候，要注意出现的时间点，错误报在那个库那个表，下次再出现的时候是否又是它。

    2、当出现 1062 错误的时候，查看 Slave 最近的一次备份，看这数据是否早存在 Slave 上了

    3、当出现 1062 错误的时候，查看 Master 和 Slave 的行记录是否一样，如果每次都是一样的，这时可以考虑是是否有定时器调存储过程进行 Insert 操作。

Slave 上报错 1062 的信息如下：

查一下 Master binlog 的记录：

可以看到 Master binlog 是插入了一条记录，登录 Master 查一下：

之前用的 binlog 格式是本来是用了默认的 mixed，后来以为有可能是 binlog 的日志格式导致了数据问题，把它修改为 ROW 了，但问题依旧存在。

查看 Slave 上的信息，可以看到 binlog 格式也是 ROW，而且设置为 read_only，行数据记录和 Master 是完全一样的，如下：

到这里是不是觉得有点怪呢，到底 Slave 上的数据是怎么来的呢？后来查看了一下与这个表相关的存储过程和定时器，如下：（相关的表名我用数字代替了，请见谅！）

Create Procedure

CREATE DEFINER=`root`@`localhost` PROCEDURE `_sp_1036`()
BEGIN DECLARE _count INT UNSIGNED DEFAULT 0; DECLARE _current_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP();SELECT COUNT(*) INTO _count FROM _1030 WHERE F04 IS NOT NULL AND F05 > _current_time;
INSERT INTO _1036 SET F01 = DATE(_current_time), F02 = HOUR(_current_time), F03 = _count ON DUPLICATE KEY UPDATE F03 = VALUES(F03);END

Create Event

CREATE DEFINER=`root`@`localhost` EVENT `_daily_sp_1036` ON SCHEDULE EVERY 1 HOUR STARTS ‘2014-01-01 00:00:00’ ON COMPLETION PRESERVE ENABLE DO CALL _sp_1036()

这个定时器一个小时运行一次，调用存储过程，向表里插入数据，其实这里的存储过程和定时器写得都没什么问题，问题在 CREATE DEFINER=`root`@`localhost`，历史留下的坑好大啊，Slave 上设置了 read_only 只对普通用户有用，对管理级别的用户是没用的，所以 Slave 上也执行了定时器到时间就执行存储过程，为了证明 Slave 有自己产生数据，我们做了测试，把 Slave 的 SQL 线程停掉：

可以看到主从同步断开的情况，每个小时整点 Slave 也会产生一条记录。Slave 上的数据是怎么来的，已经很明显了。

从上面可以看到 Master 的数据和 Slave 的是一样的，这样先把主从同步处理好，通过 set global sql_slave_skip_counter=1  跳过一个事务，如果数据不一致的情况，以 Master 的数据记录为准：

可以看到出现了跳过一个事务后，报了一条很有趣的 Log: the event’s master log FIRST。这时还是报同一条记录的主键冲突，再执行一次

可以看到同步正常了，虽然是正常了，为了保证数据的完整性，建议使用我之前写的 pt-table-checksum 校验一个数据的完整性。

讨论几个问题：

    一、为什么上面的情况有时会有报 1062 的错误，有时候没有呢？

    二、是 master 同步数据过来的时候报了 1062 错误，还是 slave 上执行定时器调存储过程时把数据插入 slave 的时候报 1062 呢？

嘻嘻，欢迎大家讨论

总结：

    一、管理好 MySQL 的权限，实现权限最小化管理，需要什么权限，开什么权限，禁止管理员级别的用户运行程序相关的任何东西。

    二、定期进行主从的数据完整性校验，确保主从的数据是一致性，特别是读写分离场景，一定要重视这类问题

本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-05/130937.htm