Mysql GTID复制进程出现异常，显露断点
发布时间：2022-03-26 03:46:12 所属栏目：MySql教程 来源：互联网
导读：昨天处理了一个MySQL 5.6版本下开启GTID模式复制异常案例，MASTER上的任何操作都无法在SLAVE上应用，SLAVE的RELAY LOG里有记录，但SLAVE的BINLOG却找不到蛛丝马迹。由于开启了GTID，所以排查起来也简单，只需要在SLAVE上把RELAY LOG和BINLOG分别解析成文本
|
昨天处理了一个MySQL 5.6版本下开启GTID模式复制异常案例，MASTER上的任何操作都无法在SLAVE上应用，SLAVE的RELAY LOG里有记录，但SLAVE的BINLOG却找不到蛛丝马迹。由于开启了GTID，所以排查起来也简单，只需要在SLAVE上把RELAY LOG和BINLOG分别解析成文本文件，再直接搜索MASTER的UUID，就能找到SLAVE上是否应用了MASTER复制过来的事务。 正常滴，在MySQL 5.6启用GTID后，部署REPLICATION复制时，可以设定 MASTER_AUTO_POSITION = 1，让 SLAVE 根据 GTID 自动选择适当的事务点进行复制，DBA基本上无需关注和担心主从不一致的问题，还是很让DBA省心的。 在启用 MASTER_AUTO_POSITION = 1 的情况下，正常是不会发生 GTID 中间有个空隙，产生断点的问题发生。除非是下面这种情况： 1、人工暂停SLAVE进程； 2、MASTER上继续写入数据； 3、MASTER上刷新LOG； 4、MASTER上删除旧BINLOG，只保留最新的BINLOG； 5、SLAVE上启动MASTER，这时候会报错，像下面这样： Last_IO_Errno: 1236 Last_IO_Error: 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.' 针对这种问题的处理方法可以这么做： 1、关闭MASTER_AUTO_POSITION，即设置 MASTER_AUTO_POSITION = 0； 2、手工CHANGE BINLOG FILE & POS； 这种情况下，不能再次设置 MASTER_AUTO_POSITION = 1，否则还会再次报错。 Retrieved_Gtid_Set: 35cc99c6-0297-11e4-9916-782bcb2c9453:1-451 Executed_Gtid_Set: 35cc99c6-0297-11e4-9916-782bcb2c9453:1-2455:792490-4517929 我们强制 SLAVE 只忽略 1-2455 这个区间，从 2466 开始继续复制，消除了本来也会被忽略的区间： 792490-4517929，确保新产生的事务都会被继续应用。这个做法可以参考MySQL手册：Excluding transactions with gtid_purged。 还有另外一种费力不讨好的做法，就是在 MASTER 上执行一些没用的空事务，使得 GTID 的序号一直在加大，直到超过 2555 为止，然后在 792490-4517929 这个区间依法炮制一番，但我们非常不推荐采用这种做法，既麻烦又容易误操作。 说了这么多，在 MySQL 5.6及以上版本中，我们强烈建议启用 MASTER_AUTO_POSITION = 1，让 MySQL 自己去做判断，减少一些不必要的问题，并且采用双主（其中一个主设为只读）的方式，方便两个主之间可以随意相互切换，而不必担心数据不一致。 上面过程我采用的MySQL版本：5.6.17-65.0-rel65.0-log Percona Server with XtraDB (GPL), Release rel65.0, Revision 587，实际案例发生的MySQL版本当时忘了记录了，但肯定也是5.6以上的啦，哈哈~~~ （编辑：源码网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
