共計 1727 個字符，預計需要花費 5 分鐘才能閱讀完成。
這篇文章主要講解了“如何修復 MySQL GTID 的混合問題”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“如何修復 MySQL GTID 的混合問題”吧！
整體服務是在兩個機房對等部署，然后通過級聯復制的方式串起來。
實際切換前，節點 B 因為是從庫，是很容易摘除的，所以整體的部署架構僅剩下 A,C,D
同時在切換前，為了保證整個業務訪問域名的可用性，會臨時開啟雙主復制，這個階段能夠最大程度保證數據的完整性。當然這里會有兩種模式，一種是最大保護模式，最大保護模式意味著數據只能從一個入口寫入，如果雙寫很可能會數據沖突，第二種是最大可用模式，也就意味著整個過程數據在兩邊始終可以寫入。這個模式的選用和具體的業務特點有關 (讀多寫少，讀多寫多等)。
所以 A 和 C 之間的雙主配置就顯得尤其重要，也是整個平滑切換數據完整性的基礎。
目前 A,C,D 節點的 GTID 基本信息如下：
A: show master status
Executed_Gtid_Set: A:1-222717169,B:1-697
C：show slave status
Executed_Gtid_Set: A:1-222716771,B:1-700
D：show slave status
Executed_Gtid_Set: A:1-222716771,B:1-700
這個數據表達的含義比較深刻，那就是在數據鏈中，存在已被摘除的節點 B 的 GTID 信息，而從 C,D 的 GTID 相關信息可以看到，B 中是丟失了一個數據事務的 (當然這個過程不是真正的數據變化，和操作不規范有關)
所以在這種情況下如果要配置雙主，需要解決的就是 B 相關 GTID 的差異，一種是直接抹去 B 的痕跡，這個過程需要在 C,D 上面可操作，但是實際復制雙主的時候又會出問題。
如果把 GTID 當做一種數據血緣的角度會發現，整個 GTID 真是一個很有靈性的設計。假設紅色是 A 的數據血緣，綠色是 B 的數據血緣。
舍棄了 B 之后，A,C 開啟了雙主，整個數據血緣就是如下的狀態了：
所以整個復制拓撲中的任何數據變化都能夠有理有據的追溯，這是 GTID 設計很有價值的一件事情。
關于修復方式，也比較清晰，那就是把 C 和 D 的數據血緣 B 的部分做下“回退”，如下：
A: show master status
Executed_Gtid_Set: A:1-222717169,B:1-697
C：show slave status
Executed_Gtid_Set: A:1-222716771,B:1-697
D：show slave status
Executed_Gtid_Set: A:1-222716771,B:1-697
按照這種模式來一次修改 C 和 D，整個雙向復制就能夠很快構建起來了。
回置 GTID 的原理可以參考如下的圖，通過 gtid_purged 可以間接實現裁剪。
C 端修復的步驟如下：
1)stop slave;
2)show slave status\G
3)reset master;
切記是在 Slave 端執行，這個階段的目的就是要重新配置 GTID 的校準值。這個時候 mysql.gtid_executed 應該就是空的了。
4) 重置 GTID_purged 值
SET @@GLOBAL.GTID_PURGED= A:1-222716771,B:1-6975) 刪除從庫的復制配置
reset slave all;6) 配置復制關系
CHANGE MASTER TO MASTER_USER= dba_repl , MASTER_PASSWORD= xxxx , MASTER_HOST= xxxxx ,MASTER_PORT=xxxx,MASTER_AUTO_POSITION = 1;
7) 重啟 Slave 節點，查看狀態
start slave; show slave status\G修復好之后，這部分打算是寫一個巡檢 GTID 和修復的腳本邏輯，能夠把這部分的管理做得更細致一些。
感謝各位的閱讀，以上就是“如何修復 MySQL GTID 的混合問題”的內容了，經過本文的學習后，相信大家對如何修復 MySQL GTID 的混合問題這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！
