GTID 是否僅在 MySQL 中優於“標準”複製？

我習慣於以老式方式設置 MySQL 複製，現在註意到有一種使用 GTID 的方法。從我讀到的內容來看，所呈現的 GTID 比“標準”複製有所改進。

但我持懷疑態度，因為如果 GTID 這麼好，我很驚訝這不是預設行為，所以我很好奇使用 GTID 是否有任何缺點？

我現在使用的是 MySQL 5.7。

最好的。

最大的優勢是自動定位。因此，您不必在開始複製時檢查並仔細檢查 binlog 文件和位置。您只需將副本指向其源，它就會根據已處理的 GTID 範圍確定從何處開始複製。

當您想要更改複製拓撲時，這大大簡化了操作。例如，當您想要更改副本以便訂閱不同的源時。您可以在故障轉移操作期間執行此操作，或者在升級期間同時處理複製。

預設情況下不啟用它的原因是為了向後兼容舊的 MySQL 部署。MySQL 從 5.6 版（大約 2013 年）開始支持 GTID，因此有很多網站沒有使用 GTID，需要進行轉換。在 MySQL 5.6 中轉換有點麻煩，所以很多網站都沒有採用 GTID。在 MySQL 5.7 中，進行了一些改進，使轉換變得更加容易。仍然有很多網站還沒有使用 GTID。

（所以我正在回答我的自我問題）

在玩了GTID幾天之後，我發現了一個不起作用的特定情況：當我需要在不同的複制集群之間定期移動數據庫時，會間歇性地複制。

我想將數據庫從複製設置遷移到另一組複製的伺服器，而不會在應用程序端造成任何停機，所以我這樣做了。

1. 創建一個mysqldump我想從活動集群主伺服器（稱為 m1）移動的數據庫的轉儲（例如使用）。
2. 在新複製設置的主節點上註入數據（主節點“m2”+ 2 個從節點）。複製執行緒應用二進制日誌中的值，GTID_NEXT並在註入結束GTID_PURGED時使用轉儲時來自主 m1 的最新 GTID 修改值。
3. 在主 m2 之間創建一個複製作為 m1 的副本，以僅在數據庫上使用複製過濾器來趕上失去的數據。
4. 當準備好進行切換時，停止 m2 上的複制從屬，並使應用程序使用 m2 作為 SQL 伺服器。

它適用於第一個數據庫移動，但不適用於後續數據庫。根據我在第 2 步對 MySQL5.7.33的經驗，複製執行緒不遵守GTID_NEXTbinlog 中的值（並創建本地 GTID），最後注入無法修改變數GTID_PURGED，因為GTID_EXECUTED不再為空。

引用自：https://dba.stackexchange.com/questions/295058