如何分析基于GTID的一主两从和主从切换

这期内容当中小编将会给大家带来有关如何分析基于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的一主两从和主从切换了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注行业资讯频道。