如何分析基于GTID的一主两从和主从更换
发布时间：2021-12-19 04:57:25 所属栏目：MySql教程 来源：互联网
导读：这期内容当中小编将会给大家带来有关如何分析基于GTID的一主两从和主从切换，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。 故障描述: 一主两从,从库2个都连的主库,主库停机, 暂定为主库为A,从库一为B,从库二为C,从库B
|
这期内容当中小编将会给大家带来有关如何分析基于GTID的一主两从和主从切换，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。 故障描述: 一主两从,从库2个都连的主库,主库停机, 暂定为主库为A,从库一为B,从库二为C,从库B比从库C更靠后,现在将从库B设为主库,从库C去连从库B,但是C从库却无法同步: B从库: mysql> show master statusG 1. row File: mysql-bin.000312 Position: 656595484 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 28aec2b2-815a-11e6-a848-6c3be5b34862:1-22169328, 2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654017 1 row in set (0.00 sec) C从库: ... 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.' ... Master_Server_Id: 1663306 Master_UUID: 28aec2b2-815a-11e6-a848-6c3be5b34862 Retrieved_Gtid_Set: 2fc072e2-7f1a-11e6-b9ec-c81f66d60579:26956787-86654006 Executed_Gtid_Set: 2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654006 Auto_Position: 1 A和B做为主库的时候都是使用的vip,且A和B的binlog文件名字不一样;(这两个条件在本案例中无关紧要,只是交代一下背景,所以不细说); 现在可以看到原来主库的86654007-86654017的事务没办法同步,在B从库(现主库)上面这个日志是存在的,没有purge; C从库直接chang master 到B从库就对了.但是指到B之后,C还是无法同步. 2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654017 这个 是停机主库的gtid,就是A 28aec2b2-815a-11e6-a848-6c3be5b34862:1-22169328 这个是B从库升级为主库后的gtid. 先讲解决方法的过程,最后在来分析问题. 解决方法: 1.C指到B后,reset slave all了一下,在change master指到vip... 不行...还是报1236; 2.重复第一次的前半部分操作,后面就直接指实体ip,也不行... 3.把C上面缺少A主库的事务,捞出来,灌进去,然后在重新指定到B,set global gtid_purged='28aec2b2-815a-11e6-a848-6c3be5b34862:1, 2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654017'; 一样报错; 4.通过B主库上的binlog日志,把缺少A主库部分的事务捞出来灌进去,然后重新指定B, SET @@GLOBAL.GTID_PURGED='28aec2b2-815a-11e6-a848-6c3be5b34862:1-75147,2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654017'; ok!成功了! 最后验证数据,数据一致! 到这,大牛估计都能看出问题在哪了.我们还是一步一步来分析吧. 首先来分析A主库停机后,B接管为主库后,C报错的信息采集: B从库: mysql> show master statusG *************************** 1. row *************************** File: mysql-bin.000312 Position: 656595484 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 28aec2b2-815a-11e6-a848-6c3be5b34862:1-22169328, 2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654017 C从库: show slave statusG ... 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.' ... Master_Server_Id: 1663306 Master_UUID: 28aec2b2-815a-11e6-a848-6c3be5b34862 Retrieved_Gtid_Set: 2fc072e2-7f1a-11e6-b9ec-c81f66d60579:26956787-86654006 Executed_Gtid_Set: 2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654006 Auto_Position: 1 从以上信息可以获取到相关信息: 1.B主库当前的GTID信息,28aec2b2-815a-11e6-a848-6c3be5b34862:1-22169328,2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654017 28aec2b2-815a-11e6-a848-6c3be5b34862:1-22169328 这个是B主库的GTID,表示在B上执行并完成到22169328这个事务来了; 2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654017 这个是A主库的GTID,表示在A上已经执行并完成到了86654017; 2.C报错信息提示:C请求的binlog在主库已经不存在了. 3.看看C执行的GTID信息: Master_UUID: 28aec2b2-815a-11e6-a848-6c3be5b34862 从这个信息看到,C做为从库已经将指定的主库为B; Retrieved_Gtid_Set: 2fc072e2-7f1a-11e6-b9ec-c81f66d60579:26956787-86654006 这里的信息是表示,C是从A主库的26956787位置开始进行同步的,且同步到86654006位置; Executed_Gtid_Set: 2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654006 这表示,从库C执行A库日志的位置,表示已经执行到86654006; 原因就是B机本身有生成gtid.(Executed_Gtid_Set: 28aec2b2-815a-11e6-a848-6c3be5b34862:1-22169328, 2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654017).28aec2b2-815a-11e6-a848-6c3be5b34862:1-22169328这个就是B本机执行的gtid.A宕机后,C从库去连接B,就要读取所B机上C未执行过的所有binlog.有点绕.意思就是,B机自己执行的gtid,C也是需要拉取并执行的.在本例中就是28aec2b2-815a-11e6-a848-6c3be5b34862:1-22169328 这些也是要执行的. B在成为主库之前已经产生了本机的gtid,分析可能是在安装好数据库之后,就开启了gtid,然后导入数据就生成了相应的gtid.因为时间又有点久.这部分binlog在B本机上已经被删除了.C去主库拉取binlog的时候,因为是第一次从B主机拉取,会从第一个gtid开始拉取,因为在B机上已经不存在这部分binlog了.所以才会报上面的错误. 问题找到了也就好解决了.解决方法上面已经说过了,不累述. gtid是全局唯一的,所以理论上,B升级为主库后,C是可以立即同步的.这个实例,也是自己操作失误,在B没有成为slave就开启了binlog,并导致这部分binlog被移除.所以,C就没办法去拉取之前生成的binlog日志. 参考这个实例,个人建议,在建立从库时,先不要开启binlog,如果从库一直没有异于主库的操作,就一直不要开启,待需要成为主库之前,在开启binlog. 上述就是小编为大家分享的如何分析基于GTID的一主两从和主从切换了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注亿速云行业资讯频道。 （编辑：东莞站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
