最近经常线上的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的信息如下:

线上Slave报1062的案例-LMLPHP

查一下Master binlog的记录:

线上Slave报1062的案例-LMLPHP

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

线上Slave报1062的案例-LMLPHP

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

mixed格式的问题可以参考:http://mp.weixin.qq.com/s?__biz=MjM5MjIxNDA4NA==&mid=400804310&idx=1&sn=2ea8b7455688a41621b8c9b59fbf822e&scene=0#wechat_redirect

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

线上Slave报1062的案例-LMLPHP

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

Create Procedure

CREATE DEFINER=`root`@`localhost` PROCEDURE `_sp_1036`()
BEGIN DECLARE _count INT UNSIGNED DEFAULT ; 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 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报1062的案例-LMLPHP

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

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

线上Slave报1062的案例-LMLPHP

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

线上Slave报1062的案例-LMLPHP

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

讨论几个问题:

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

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

嘻嘻,欢迎大家讨论

总结:

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

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

作者:陆炫志

出处:xuanzhi的博客 http://www.cnblogs.com/xuanzhi201111

您的支持是对博主最大的鼓励,感谢您的认真阅读。本文版权归作者所有,欢迎转载,但请保留该声明。

05-11 14:11