码迷,mamicode.com
首页 > 数据库 > 详细

MySQL 5.7基于GTID复制的常见问题和修复步骤(二)

时间:2018-11-23 16:47:43      阅读:300      评论:0      收藏:0      [点我收藏+]

标签:nlog   工具   top   sum   span   问题   lob   art   tps   

 

【问题二】

有一个集群(MySQL5.7.23)切换后复制slave报1236,其实是不小心在slave上执行了事务导致

Got fatal error 1236 from master when reading data from binary log: ‘The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.

【产生原因】

定时任务在执行flush slow logs前未加set sql_log_bin=0;导致在slave上执行时,slave上的GTID增长,当binlog日志被purge后,发生MHA切换后就会报出上面的错误。

 技术分享图片

【修复步骤】

下面描述正确的处理步骤:

1、切换后如果出现replication报错,第一时间先关闭master的binlog备份

2、修复导致slave事务增长的job脚本set sql_log_bin=0; flush slow logs

3、slave上stop slave;

4、master上show global variables like ‘%gtid%‘;记录gtid_purged,gtid_executed值

 技术分享图片

5、slave上reset master;

6、slave上set global gtid_purged=‘3d9ade83-7cea-11e5-bc12-d89d6725f98c:1-863017556,

8fad86b1-8980-11e8-873d-40a8f024a124:1-24531;

这里需要注意,设置的值应该是上面截图红色框两段组合的值,这样才能保证再次切换后复制正常

7、slave上start slave;

对于这次的场景,按上次步骤恢复后会丢失8fad86b1-8980-11e8-873d-40a8f024a124:1-24531这段事务,但这段事务实际上是flush slow logs事务,并不影响业务数据,因此理论上数据会一致

上述方法修复后,建议用pt-table-checksum工具,检验主从数据的一致性。

复制相关的文章

MySQL 5.7基于GTID复制的常见问题和修复步骤(一)

 技术分享图片

MySQL 5.7基于GTID复制的常见问题和修复步骤(二)

标签:nlog   工具   top   sum   span   问题   lob   art   tps   

原文地址:https://www.cnblogs.com/wangdong/p/10008361.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!