MySQL :: MySQL 8.4 參考手冊 :: 19.5.4 疑難排解複製

版本 8.4

9.0
8.0
5.7

8.0 日文

MySQL 8.4 參考手冊 / ... / 疑難排解複製

19.5.4 疑難排解複製

如果您已依照指示操作，但您的複製設定無法運作，第一件事就是檢查錯誤日誌中的訊息。許多使用者因為遇到問題後沒有及早這樣做而浪費時間。

如果您無法從錯誤日誌中判斷問題所在，請嘗試下列方法

發出 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 節「如何回報複製錯誤或問題」，以取得如何回報的說明。
如果某個在來源上成功的陳述式拒絕在副本上執行，如果無法透過刪除副本的資料庫並從來源複製新的快照來執行完整的資料庫重新同步，請嘗試以下程序
1. 確定副本上受影響的表格是否與來源表格不同。嘗試了解這是如何發生的。然後，使副本的表格與來源的表格相同，並執行 START REPLICA。
2. 如果上述步驟無效或不適用，請嘗試了解手動進行更新是否安全 (如果需要)，然後忽略來自來源的下一個陳述式。
3. 如果您決定副本可以跳過來自來源的下一個陳述式，請發出以下陳述式
```
mysql> SET GLOBAL sql_replica_skip_counter = N;
mysql> START REPLICA;
```
  N 的值，如果來自來源的下一個陳述式未使用 AUTO_INCREMENT 或 LAST_INSERT_ID()，則應該是 1。否則，該值應該是 2。對使用 AUTO_INCREMENT 或 LAST_INSERT_ID() 的陳述式使用值 2 的原因是，它們在來源的二進位日誌中會產生兩個事件。
4. 如果您確定副本的開始與來源完全同步，並且沒有人在複製執行緒之外更新涉及的表格，那麼這種差異可能是錯誤的結果。如果您正在執行最新版本的 MySQL，請回報問題。如果您正在執行舊版本，請嘗試升級到最新的生產版本，以確定問題是否仍然存在。