这期内容当中小编将会给大家带来有关如何分析基于GTID的一主两从和主从切换，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
故障描述:
一主两从,从库2个都连的主库,主库停机, 暂定为主库为A,从库一为B,从库二为C,从库B比从库C更靠后,现在将从库B设为主库,从库C去连从库B,但是C从库却无法同步:
B从库:
mysql> show master status\G
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 status\G
*************************** 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 status\G
...
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的一主两从和主从切换了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联-成都网站建设公司行业资讯频道。
