如何分析基于GTID的一主兩從和主從切換

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

故障描述:
一主兩從,從庫(kù)2個(gè)都連的主庫(kù),主庫(kù)停機(jī), 暫定為主庫(kù)為A,從庫(kù)一為B,從庫(kù)二為C,從庫(kù)B比從庫(kù)C更靠后,現(xiàn)在將從庫(kù)B設(shè)為主庫(kù),從庫(kù)C去連從庫(kù)B,但是C從庫(kù)卻無(wú)法同步:


B從庫(kù):
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從庫(kù):
                ...
                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做為主庫(kù)的時(shí)候都是使用的vip,且A和B的binlog文件名字不一樣;(這兩個(gè)條件在本案例中無(wú)關(guān)緊要,只是交代一下背景,所以不細(xì)說(shuō));
現(xiàn)在可以看到原來(lái)主庫(kù)的86654007-86654017的事務(wù)沒(méi)辦法同步,在B從庫(kù)(現(xiàn)主庫(kù))上面這個(gè)日志是存在的,沒(méi)有purge;
C從庫(kù)直接chang master 到B從庫(kù)就對(duì)了.但是指到B之后,C還是無(wú)法同步.


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


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

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


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

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

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