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

157次閱讀

共計 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 行業資訊頻道。

正文完