如何分析基于GTID的一主兩從和主從切換-創(chuàng)新互聯(lián)

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

創(chuàng)新互聯(lián)成立與2013年，先為堯都等服務建站，堯都等地企業(yè)，進行企業(yè)商務咨詢服務。為堯都企業(yè)網站制作PC+手機+微官網三網同步一站式服務解決您的所有建站問題。

故障描述:
一主兩從,從庫2個都連的主庫,主庫停機, 暫定為主庫為A,從庫一為B,從庫二為C,從庫B比從庫C更靠后,現(xiàn)在將從庫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文件名字不一樣;(這兩個條件在本案例中無關緊要,只是交代一下背景,所以不細說);
現(xiàn)在可以看到原來主庫的86654007-86654017的事務沒辦法同步,在B從庫(現(xiàn)主庫)上面這個日志是存在的,沒有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!成功了!
   最后驗證數(shù)據(jù),數(shù)據(jù)一致!
   

到這,大牛估計都能看出問題在哪了.我們還是一步一步來分析吧.
首先來分析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上執(zhí)行并完成到22169328這個事務來了;
      2fc072e2-7f1a-11e6-b9ec-c81f66d60579:1-86654017   這個是A主庫的GTID,表示在A上已經執(zhí)行并完成到了86654017;
    2.C報錯信息提示:C請求的binlog在主庫已經不存在了.
    3.看看C執(zhí)行的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執(zhí)行A庫日志的位置,表示已經執(zhí)行到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本機執(zhí)行的gtid.A宕機后,C從庫去連接B,就要讀取所B機上C未執(zhí)行過的所有binlog.有點繞.意思就是,B機自己執(zhí)行的gtid,C也是需要拉取并執(zhí)行的.在本例中就是28aec2b2-815a-11e6-a848-6c3be5b34862:1-22169328 這些也是要執(zhí)行的.
    B在成為主庫之前已經產生了本機的gtid,分析可能是在安裝好數(shù)據(jù)庫之后,就開啟了gtid,然后導入數(shù)據(jù)就生成了相應的gtid.因為時間又有點久.這部分binlog在B本機上已經被刪除了.C去主庫拉取binlog的時候,因為是第一次從B主機拉取,會從第一個gtid開始拉取,因為在B機上已經不存在這部分binlog了.所以才會報上面的錯誤.


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

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

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

新聞名稱：如何分析基于GTID的一主兩從和主從切換-創(chuàng)新互聯(lián)
轉載源于：http://muchs.cn/article24/cdjcce.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、品牌網站制作、移動網站建設、App設計、搜索引擎優(yōu)化、靜態(tài)網站

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)

成都app開發(fā)公司