如果一個陳述式在來源和副本上產生相同的錯誤(相同的錯誤代碼),則會記錄錯誤,但複製會繼續。
如果一個陳述式在來源和副本上產生不同的錯誤,則複製 SQL 執行緒會終止,而副本會將訊息寫入其錯誤日誌,並等待資料庫管理員決定如何處理該錯誤。這包括陳述式在來源或副本上產生錯誤,但兩者並非都產生錯誤的情況。若要解決此問題,請手動連線到副本並判斷問題的原因。SHOW REPLICA STATUS
對此很有用。然後修復問題並執行 START REPLICA
。例如,您可能需要建立一個不存在的表格,才能再次啟動副本。
如果在副本的錯誤日誌中記錄了暫時性錯誤,您不一定需要採取引用錯誤訊息中建議的任何動作。暫時性錯誤應由重新嘗試交易的用戶端處理。例如,如果複製 SQL 執行緒記錄了與死鎖相關的暫時性錯誤,則您不需要在副本上手動重新啟動交易,除非複製 SQL 執行緒隨後終止並顯示非暫時性錯誤訊息。
如果此錯誤代碼驗證行為不可取,則可以使用 --replica-skip-errors
選項遮罩(忽略)部分或所有錯誤。
對於非交易性儲存引擎(例如 MyISAM
),有可能發生一個陳述式僅部分更新表格並傳回錯誤代碼的情況。例如,這可能會發生在具有一列違反金鑰限制的多列插入時,或者如果長時間更新陳述式在更新部分列之後被終止。如果這種情況發生在來源上,則副本會預期該陳述式的執行會產生相同的錯誤代碼。如果沒有,則複製 SQL 執行緒會如先前所述停止。
如果您在來源和副本上使用不同儲存引擎的資料表之間進行複製,請記住,當針對資料表的一個版本執行時,相同的陳述式可能會產生不同的錯誤,或者可能會導致資料表的一個版本出現錯誤,而另一個版本則不會。例如,由於 MyISAM
忽略外鍵約束,因此在來源上存取 InnoDB
資料表的 INSERT
或 UPDATE
陳述式可能會導致外鍵違規,但在副本上對同一個資料表的 MyISAM
版本執行相同陳述式時,則不會產生此類錯誤,從而導致複製停止。
複製篩選規則會優先於執行任何權限或列格式檢查之前套用,從而可以篩選掉任何驗證失敗的交易;對於已篩選掉的交易,不會執行任何檢查,因此不會引發任何錯誤。這表示副本只能接受已授予特定使用者存取權限的資料庫部分(只要對資料庫此部分的任何更新都使用基於列的複製格式)。當執行升級或遷移到使用入站複製使用者無法存取的管理資料表的系統或應用程式時,這可能會有所幫助。另請參閱 第 19.2.5 節,「伺服器如何評估複製篩選規則」。