MySQL 9.0 版本注意事項
如果您已遵循指示，但您的複製設定無法運作，首先要做的是檢查錯誤日誌中的訊息。許多使用者在遇到問題後沒有盡早這麼做而浪費了時間。
如果您無法從錯誤日誌判斷問題所在，請嘗試下列技巧
發出
SHOW BINARY LOG STATUS陳述式，驗證來源是否已啟用二進位記錄。預設會啟用二進位記錄。如果啟用二進位記錄，Position為非零。如果未啟用二進位記錄，請驗證您是否未以任何停用二進位記錄的設定執行來源，例如--skip-log-bin選項。驗證在來源和複本上啟動時是否已設定
server_id系統變數，且每個伺服器上的 ID 值都是唯一的。驗證複本是否正在執行。使用
SHOW REPLICA STATUS檢查Replica_IO_Running和Replica_SQL_Running值是否皆為Yes。如果不是，請驗證啟動複本伺服器時使用的選項。例如，--skip-replica-start會防止複製執行緒啟動，直到您發出START REPLICA陳述式為止。如果複本正在執行，請檢查它是否已建立與來源的連線。使用
SHOW PROCESSLIST，找到 I/O (接收器) 和 SQL (應用程式) 執行緒，並檢查它們的State欄位，以查看它們顯示的內容。請參閱 第 19.2.3 節「複製執行緒」。如果接收器執行緒狀態顯示Connecting to master，請檢查以下事項：驗證來源上複製使用者的權限。
檢查來源的主機名稱是否正確，以及您是否使用正確的連接埠連接到來源。用於複製的連接埠與用於用戶端網路通訊的連接埠相同（預設為
3306）。對於主機名稱，請確保該名稱解析為正確的 IP 位址。檢查組態檔，以查看是否在來源或複本上啟用了
skip_networking系統變數來停用網路功能。如果是，請註解該設定或將其移除。如果來源具有防火牆或 IP 篩選組態，請確保未篩選用於 MySQL 的網路連接埠。
檢查是否可以使用
ping或traceroute/tracert連線到主機來連線到來源。
如果複本先前正在執行但已停止，原因通常是某些在來源上成功的陳述式在複本上失敗。如果您已正確擷取來源的快照，並且從未在複製執行緒之外修改複本上的資料，則不應發生這種情況。如果複本意外停止，則表示存在錯誤，或者您遇到了 第 19.5.1 節「複製功能與問題」 中所述的已知複製限制之一。如果是錯誤，請參閱 第 19.5.5 節「如何報告複製錯誤或問題」，以取得有關如何報告錯誤的指示。
如果一個在來源上成功的陳述式拒絕在複本上執行，如果無法通過刪除複本的資料庫並從來源複製新的快照來執行完整的資料庫重新同步，請嘗試以下程序：
確定複本上受影響的資料表是否與來源資料表不同。嘗試了解這是如何發生的。然後使複本的資料表與來源的資料表相同，並執行
START REPLICA。如果上述步驟無效或不適用，請嘗試了解手動執行更新是否安全 (如果需要)，然後忽略來源的下一個陳述式。
如果您確定複本可以跳過來源的下一個陳述式，請發出以下陳述式：
mysql> SET GLOBAL sql_replica_skip_counter = N; mysql> START REPLICA;N的值應為 1，如果來源的下一個陳述式未使用AUTO_INCREMENT或LAST_INSERT_ID()。否則，該值應為 2。對於使用AUTO_INCREMENT或LAST_INSERT_ID()的陳述式使用值 2 的原因是，它們在來源的二進位記錄中需要兩個事件。如果您確定複本一開始與來源完全同步，並且沒有人在複製執行緒之外更新相關的資料表，那麼可能差異是錯誤造成的。如果您正在執行最新版本的 MySQL，請回報問題。如果您正在執行舊版本，請嘗試升級到最新的生產版本，以確定問題是否仍然存在。