MySQL 9.0 版本注意事項
當您確定沒有使用者錯誤，而複製仍然無法運作或不穩定時，就該將錯誤報告給我們。我們需要從您那裡取得盡可能多的資訊，才能追蹤到錯誤。請花一些時間與精力準備一份良好的錯誤報告。
如果您有一個可重複的測試案例可以示範該錯誤，請依照第 1.6 節，「如何回報錯誤或問題」中的指示，將其輸入到我們的錯誤資料庫中。如果您有「「phantom」」問題（您無法隨意複製的問題），請使用下列程序
確認沒有使用者錯誤。例如，如果您在複製執行緒之外更新複本，資料會失去同步，並且在更新時可能會發生唯一鍵衝突。在這種情況下，複製執行緒會停止並等待您手動清除資料表，使其重新同步。這不是複製問題。這是外部干擾導致複製失敗的問題。
確保複本在啟用二進制日誌記錄的情況下執行（
log_bin系統變數），並且啟用--log-replica-updates選項，這會導致複本將從來源接收的更新記錄到自己的二進制日誌中。這些設定是預設值。在重設複製狀態之前，請儲存所有證據。如果我們沒有任何資訊或只有粗略的資訊，我們就很難或不可能追蹤到問題。您應該收集的證據如下
來源的所有二進制日誌檔案
複本的所有二進制日誌檔案
當您發現問題時，來源的
SHOW BINARY LOG STATUS輸出當您發現問題時，複本的
SHOW REPLICA STATUS輸出來自來源端和複本端的錯誤日誌
使用 mysqlbinlog 來檢查二進制日誌。以下資訊應有助於找出問題陳述。
log_file和log_pos是來自SHOW REPLICA STATUS的Master_Log_File和Read_Master_Log_Pos值。$> mysqlbinlog --start-position=log_pos log_file | head
當您收集到問題的證據後，請先嘗試將其隔離為一個單獨的測試案例。然後使用 第 1.6 節，「如何回報錯誤或問題」 中的說明，將問題盡可能詳細地輸入到我們的錯誤資料庫中。