這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)如何分析基于GTID的一主兩從和主從切換，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

成都創(chuàng)新互聯(lián)專注于四子王企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站建設(shè),商城網(wǎng)站建設(shè)。四子王網(wǎng)站建設(shè)公司,為四子王等地區(qū)提供建站服務(wù)。全流程按需定制，專業(yè)設(shè)計，全程項(xiàng)目跟蹤，成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

故障描述:
一主兩從,從庫2個都連的主庫,主庫停機(jī), 暫定為主庫為A,從庫一為B,從庫二為C,從庫B比從庫C更靠后,現(xiàn)在將從庫B設(shè)為主庫,從庫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文件名字不一樣;(這兩個條件在本案例中無關(guān)緊要,只是交代一下背景,所以不細(xì)說);
現(xiàn)在可以看到原來主庫的86654007-86654017的事務(wù)沒辦法同步,在B從庫(現(xiàn)主庫)上面這個日志是存在的,沒有purge;
C從庫直接chang master 到B從庫就對了.但是指到B之后,C還是無法同步.


2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654017  這個 是停機(jī)主庫的gtid,就是A
28aec2b2-815a-11e6-a848-6c3be5b34862:1-22169328  這個是B從庫升級為主庫后的gtid.


先講解決方法的過程,最后在來分析問題.
解決方法:
   1.C指到B后,reset slave all了一下,在change master指到vip... 不行...還是報1236;
   2.重復(fù)第一次的前半部分操作,后面就直接指實(shí)體ip,也不行...
   3.把C上面缺少A主庫的事務(wù),撈出來,灌進(jìn)去,然后在重新指定到B,set global gtid_purged='28aec2b2-815a-11e6-a848-6c3be5b34862:1,
2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654017';  一樣報錯;
   4.通過B主庫上的binlog日志,把缺少A主庫部分的事務(wù)撈出來灌進(jìn)去,然后重新指定B, SET @@GLOBAL.GTID_PURGED='28aec2b2-815a-11e6-a848-6c3be5b34862:1-75147,2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654017';
   ok!成功了!
   最后驗(yàn)證數(shù)據(jù),數(shù)據(jù)一致!
   

到這,大牛估計都能看出問題在哪了.我們還是一步一步來分析吧.
首先來分析A主庫停機(jī)后,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

從以上信息可以獲取到相關(guān)信息:
    1.B主庫當(dāng)前的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上執(zhí)行并完成到22169328這個事務(wù)來了;
      2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654017   這個是A主庫的GTID,表示在A上已經(jīng)執(zhí)行并完成到了86654017;
    2.C報錯信息提示:C請求的binlog在主庫已經(jīng)不存在了.
    3.看看C執(zhí)行的GTID信息:
        Master_UUID: 28aec2b2-815a-11e6-a848-6c3be5b34862      從這個信息看到,C做為從庫已經(jīng)將指定的主庫為B;
        Retrieved_Gtid_Set: 2fc072e2-7f1a-11e6-b9ec-c81f66d60579:26956787-86654006   這里的信息是表示,C是從A主庫的26956787位置開始進(jìn)行同步的,且同步到86654006位置;
        Executed_Gtid_Set: 2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654006  這表示,從庫C執(zhí)行A庫日志的位置,表示已經(jīng)執(zhí)行到86654006;
    
    原因就是B機(jī)本身有生成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本機(jī)執(zhí)行的gtid.A宕機(jī)后,C從庫去連接B,就要讀取所B機(jī)上C未執(zhí)行過的所有binlog.有點(diǎn)繞.意思就是,B機(jī)自己執(zhí)行的gtid,C也是需要拉取并執(zhí)行的.在本例中就是28aec2b2-815a-11e6-a848-6c3be5b34862:1-22169328 這些也是要執(zhí)行的.
    B在成為主庫之前已經(jīng)產(chǎn)生了本機(jī)的gtid,分析可能是在安裝好數(shù)據(jù)庫之后,就開啟了gtid,然后導(dǎo)入數(shù)據(jù)就生成了相應(yīng)的gtid.因?yàn)闀r間又有點(diǎn)久.這部分binlog在B本機(jī)上已經(jīng)被刪除了.C去主庫拉取binlog的時候,因?yàn)槭堑谝淮螐腂主機(jī)拉取,會從第一個gtid開始拉取,因?yàn)樵贐機(jī)上已經(jīng)不存在這部分binlog了.所以才會報上面的錯誤.


問題找到了也就好解決了.解決方法上面已經(jīng)說過了,不累述.

gtid是全局唯一的,所以理論上,B升級為主庫后,C是可以立即同步的.這個實(shí)例,也是自己操作失誤,在B沒有成為slave就開啟了binlog,并導(dǎo)致這部分binlog被移除.所以,C就沒辦法去拉取之前生成的binlog日志.
參考這個實(shí)例,個人建議,在建立從庫時,先不要開啟binlog,如果從庫一直沒有異于主庫的操作,就一直不要開啟,待需要成為主庫之前,在開啟binlog.

上述就是小編為大家分享的如何分析基于GTID的一主兩從和主從切換了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。