如何分析基于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的一主兩從和主從切換了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。