MySQL：從 GTID 集中刪除錯誤的 GTID

MySQL 5.6.35-日誌（社區）

如何在不執行 RESET MASTER 的情況下從 GTID 集中刪除錯誤手動注入的 GTID？

STOP SLAVE;
SHOW MASTER STATUS;

278bfda1-b93d-11e4-801b-14feb5d284bc:1-129116182,
69cf02cd-1731-11e3-9a19-002590854928:1-649285403:1009231661,
708bb615-d393-11e3-a682-003048c3ab22:1-1009669227,
819c985c-d384-11e3-a621-00259002979a:1-234906555,
9204e764-d379-11e3-a5d9-0013726268ea:1-360176454,
c32252c2-1ce5-11e6-8f4b-c80aa91f9ec4:1

我們需要從這個集合中刪除 GTID 1009231661：

69cf02cd-1731-11e3-9a19-002590854928:1-649285403:1009231661,

有誰知道 GTID 集的儲存位置/方式？我在 5.7 文件中讀到 GTID 儲存在表中。但是它們在 5.6 中儲存在哪裡？我想關閉伺服器，編輯文件，刪除錯誤的 GTID，然後重新啟動，以便伺服器可以啟動並繼續。

對於那些在以後的生活中發現這一點的人..

這是一個災難性的錯誤。沒有辦法解決這個問題。必須在整個農場範圍內執行 RESET MASTER / CHANGE MASTER TO。為什麼會如此災難性？因為，在多主循環複製中，所有 MySQL 伺服器都需要執行 RESET MASTER / CHANGE MASTER TO。

在 MySQL 5.6 中，GTID 集儲存在主 BINLOG 文件中 - 因此必須執行 RESET MASTER。但是，當您執行 RESET MASTER 時，該命令還會將上次使用的伺服器 GTID 重置為 0。現在從伺服器的 GTID 大於主伺服器。從伺服器將跳過事務，直到 GTID 超過主伺服器的從伺服器 GTID_EXECUTED_SET 值。這就是為什麼您也必須在所有從屬伺服器上執行 RESET MASTER / CHANGE MASTER TO。

在執行 RESET MASTER / CHANGE MASTER TO 之後，我們應該只需要轉儲/恢復受影響的主伺服器（又名主數據庫）上正在更新的數據庫，以便它們可以同步。

我認為解決這個問題的正確方法是在執行錯誤的 GTID 之前執行從站。START SLAVE支持一個**UNTIL**子句。在此處閱讀更多相關資訊。

然後，您可以插入一個空交易，讓壞交易跳過它。

STOP SLAVE;
SET GTID_NEXT="GTID_you_want_to_skip";
BEGIN; COMMIT;
#now resume just as normal:
SET GTID_NEXT="AUTOMATIC";
START SLAVE;

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