阿里云-云小站(无限量代金券发放中)
【腾讯云】云服务器、云数据库、COS、CDN、短信等热卖云产品特惠抢购

线上Slave报1062的案例

210次阅读
没有评论

共计 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 的信息如下:

线上 Slave 报 1062 的案例

查一下 Master binlog 的记录:

线上 Slave 报 1062 的案例

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

线上 Slave 报 1062 的案例

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

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

线上 Slave 报 1062 的案例

到这里是不是觉得有点怪呢,到底 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 报 1062 的案例

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

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

线上 Slave 报 1062 的案例

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

线上 Slave 报 1062 的案例

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

讨论几个问题:

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

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

嘻嘻,欢迎大家讨论

总结:

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

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

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

正文完
星哥玩云-微信公众号
post-qrcode
 0
星锅
版权声明:本站原创文章,由 星锅 于2022-01-22发表,共计2038字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
【腾讯云】推广者专属福利,新客户无门槛领取总价值高达2860元代金券,每种代金券限量500张,先到先得。
阿里云-最新活动爆款每日限量供应
评论(没有评论)
验证码
【腾讯云】云服务器、云数据库、COS、CDN、短信等云产品特惠热卖中