我有一對帶有 MySQL 5.6.23 的 Debian 7 伺服器。從伺服器是主伺服器的複製（但 uuid 已在從伺服器上重新生成）。

出於某種原因，每當通過“ service mysql restart”在 Master 上重新啟動 MySQL 時，Slave 都會繼續讀取 Master_Log_File 和 Read_Master_Log_Pos，但不會處理 Relay_Master_Log_File。

從 I/O 和從 SQL 都在執行，但 Seconds_Behind_Master 繼續遞增。

Slave_SQL_Running_State 說“ Waiting for Slave Worker to release partition。”

很明顯，我已經嘗試停止和啟動slave，重啟slave和master上的mysql服務，重啟slave和master伺服器。

要解決這個問題，我必須清空並重新創建從站。我通過我製作的腳本來轉儲主文件和位置，使用 mysqldump 將數據庫拉到從屬設備上，然後從記錄的主文件和位置開始從屬。mysqldump 標誌是--skip-lock-tables --flush-logs --hex-blob --master-data=2 --single-transaction --comments --routines

我錯過了什麼嗎？任何幫助是極大的讚賞。

你猜怎麼了 ？你有一個討厭的小錯誤（多執行緒複製的複制停滯）

這個 bug 最早是在 MySQL 5.6.17 上報告的20 Jun 2014 15:45

建議 #1

您需要查看MySQL 5.6.18up to的所有發行說明MySQL 5.6.22以查看是否已解決。如果這些發行說明中的任何一個聲稱問題已得到解決，那麼有人錯過了更新檔。我建議您不要回歸到 MySQL 5.6.21 之前的任何內容（從 MySQL 5.1.73 升級到 5.6.21 的任何已知問題？下ISSUE #3 : Security Issues）

建議 #2

在修復此錯誤之前，請勿使用多執行緒複製。

建議#3

在前面提到的錯誤報告中，它在中間的某個地方說這個

當 MySQL 再次恢復時，日誌會旋轉，IO 執行緒從部分寫入的事件組開始寫入。

. . .

你可以看到我之前展示的部分事件和這個事件的“end_log_pos”值是相同的。它是部分寫入的同一個 UPDATE 事務。

現在是有趣的部分。當協調器讀取中繼日誌時，它將部分事件發送給工作人員，因為事件是部分的，因此工作人員從不送出事務並且事務保持打開狀態。協調器讀取下一個事件（這是部分事件的完整版本），但協調器無法將下一個事件分配給另一個工作人員，因為其中一個工作人員有一個打開的事務。

顯然，當 MTS 看到日誌輪換時，它會等待工作人員送出事務。

我建議不要--flush-logs與 mysqldump 一起使用，以防萬一存在一些由 mysqldump 突然拆分的組送出問題，並且此錯誤無法正確查看傳入的 binlog 事件。

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