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

共计 4061 个字符，预计需要花费 11 分钟才能阅读完成。

这期内容当中丸趣 TV 小编将会给大家带来有关如何分析基于 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.

上述就是丸趣 TV 小编为大家分享的如何分析基于 GTID 的一主两从和主从切换了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注丸趣 TV 行业资讯频道。