我已經設置了基於 5.6 gtid 的複制（在 5.6.26 上），當我這樣做時它似乎可以工作，它複製了我在正常數據旁邊創建的隨機測試數據庫。但是在某些時候一定發生了一些事情，因為我所看到的只是：

mysql> 顯示從屬狀態\G
****************************** 1. 行 ************************ *******
Slave_IO_State：系統鎖
Master_Host：xxxxxxxxxxxxxxxxxx
主使用者：xxxxxxxxxxxxxxx
主埠：3306
連接重試：60
Master_Log_File：mysqld-bin.000141
Read_Master_Log_Pos：169293671
Relay_Log_File：mysqld-relay-bin.000003
Relay_Log_Pos：16861206
Relay_Master_Log_File：mysqld-bin.000141
Slave_IO_Running：是
Slave_SQL_Running：是
Replicate_Do_DB：
Replicate_Ignore_DB：
Replicate_Do_Table：
Replicate_Ignore_Table：
Replicate_Wild_Do_Table：
Replicate_Wild_Ignore_Table：
Last_Errno: 0
最後_錯誤：
跳過計數器：0
Exec_Master_Log_Pos：16860994
中繼日誌空間：169298584
直到_條件：無
直到_Log_File：
直到_Log_Pos：0
Master_SSL_Allowed：否
Master_SSL_CA_文件：
Master_SSL_CA_Path：
Master_SSL_Cert：
Master_SSL_Cipher：
Master_SSL_Key：
Seconds_Behind_Master：55203
Master_SSL_Verify_Server_Cert：否
Last_IO_Errno: 0
Last_IO_Error：
Last_SQL_Errno: 0
Last_SQL_Error：
Replicate_Ignore_Server_Ids：
Master_Server_Id：1
Master_UUID：7846a847-62c7-11e5-91a6-e06995de432e
Master_Info_File：mysql.slave_master_info
SQL_延遲：0
SQL_Remaining_Delay：空
Slave_SQL_Running_State：系統鎖
Master_Retry_Count：86400
主綁定：
Last_IO_Error_Timestamp：
Last_SQL_Error_Timestamp：
Master_SSL_Crl：
Master_SSL_Crlpath：
Retrieved_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:4757140-5030085
Executed_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:1-4783274
自動位置：1

現在最初的“Slave_SQL_Running_State”表示“從中繼日誌讀取事件”或類似的東西，現在它也變成了系統鎖（IO 狀態總是這麼說）。

似乎在Seconds_Behind_Master穩步增長，並且中繼日誌在文件系統上的大小迅速增長，雖然Executed_gtid_set似乎確實發生了變化，但似乎仍然有些問題，因為它落後了太多……

以下是流程清單：

mysql> 顯示程序列表；
+------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+
| 身份證 | 使用者 | 主持人 | 分貝 | 命令 | 時間 | 狀態 | 資訊 |
+------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+
| 1877 | 根 | 本地主機 | 空 | 睡眠 | 6076 | | 空 |
| 1878 | 根 | 本地主機 | 空 | 查詢 | 0 | 初始化 | 顯示程序列表 |
| 1886 | 系統使用者 | | 空 | 連接 | 第783章 系統鎖 | 空 |
| 1887 | 系統使用者 | | 空 | 連接 | 0 | 系統鎖 | 空 |
| 1888 | 系統使用者 | | 空 | 連接 | 第783章 等待來自 Coordinator 的事件 | 空 |
| 1889 | 系統使用者 | | 空 | 連接 | 55455 | 系統鎖 | 空 |
+------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+

我試圖停止奴隸並重新啟動它，但它沒有幫助。

有沒有人有任何想法我可以嘗試再次使這項工作？將不勝感激。

謝謝

由於我在程序列表中看到超過 2system user個條目，因此我假設您正在使用多執行緒複製（slave_parallel_workers > 1）。

這看起來像一個錯誤

• 錯誤 #73066：多執行緒複製的複制停滯
• 錯誤 #72794：沒有 xid_log_event 的中繼日誌可能會導致並行複制掛起

2014 年 10 月 29 日，這表示為David Moss

感謝您的回饋意見。此問題已包含在錯誤 17326020 中，並且以下內容已添加到 MySQL 5.6.21 和 5.7.5 更改日誌中：

當 I/O 執行緒在事務中間使用 GTID 和多執行緒從屬重新連接到主伺服器時，它未能中止事務，在中繼日誌中留下部分事務，然後再次檢索相同的事務。這發生在執行中繼日誌的輪換時。現在重新連接時，伺服器會在這種情況下輪換日誌之前進行檢查，並首先等待任何正在進行的事務完成。

因此，不會添加任何新內容來覆蓋此錯誤，我將按固定方式關閉它。

2014 年 12 月 10 日，這表示為Laurynas Biveinis

問題：

啟用 MTS、GTID 和自動定位後，當工作人員應用 IO 執行緒重新連接留下的部分事務時，它將等待 XID 日誌事件送出事務。

不幸的是，SQL 執行緒協調器將在下一個中繼日誌文件上到達 master 的 ROTATE 事件，並在應用 ROTATE 之前等待所有工作人員完成他們的任務。

分析：

由於整個事務在重新連接後被 IO 執行緒再次檢索，所以一旦從 master 注意到這個 ROTATE，slave 必須回滾部分事務。

此錯誤報告了已由 BUG#17326020 修復的相同問題，並且報告的問題不再可重現。所以，這個更新檔只是添加了一個新的測試案例。

建議

FLUSH BINARY LOGS;在主上執行

查看移動是否觸發了 SQL 執行緒的響應。

如果沒有，請繼續並從中刪除slave_parallel_workers並my.cnf重新啟動 mysql。

由於您啟動了 MySQL 並且 master 和 slave 並 got error 1236，這意味著您正試圖從一個不可能的位置建立複製。在您收到的 GTID 和錯誤消息的上下文中，完全辨識 GTID 集中的一組查詢所需的二進制日誌不再存在，

回頭看看你的SHOW SLAVE STATUS\G

Retrieved_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:4757140-5030085
Executed_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:1-4783274

由此，最後執行的 GTID 是7846a847-62c7-11e5-91a6-e06995de432e:4783274

這意味著已經存在或曾經7846a847-62c7-11e5-91a6-e06995de432e:4783275不存在的二進制日誌。

如果您停止從屬伺服器上的複制，我可以看到這種情況發生，讓複製停止足夠長的時間讓主伺服器輪換其二進制日誌（通過 expire_logs_days），從屬伺服器仍然需要查看，然後打開複製。

在您的特定情況下，請嘗試對二進制日誌進行 mysqlbinlog 轉儲mysqld-bin.000141。如果沒有任何結果，您將不得不重新載入從站並從頭開始設置複製。

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