ステートメントがソースとレプリカの両方で同じエラー (同一のエラーコード) を生成した場合、エラーはログに記録されますが、レプリケーションは続行されます。
ステートメントがソースとレプリカで異なるエラーを生成すると、レプリケーション SQL スレッドは終了し、レプリカはエラーログにメッセージを書き込み、データベース管理者がエラーに関する処理を決定するのを待機します。 これには、ステートメントがソースまたはレプリカでエラーを生成する場合が含まれますが、両方ではありません。 この問題に対処するには、レプリカに手動で接続し、問題の原因を特定します。 これには、SHOW REPLICA | SLAVE STATUS が役立ちます。 次に、問題を修正し、START REPLICA | SLAVE を実行します。 たとえば、レプリカを再起動する前に、存在しないテーブルを作成する必要がある場合があります。
レプリカエラーログに一時エラーが記録されている場合は、引用符で囲まれたエラーメッセージに示されているアクションを実行する必要はありません。 一時エラーは、トランザクションを再試行するクライアントによって処理される必要があります。 たとえば、レプリケーション SQL スレッドがデッドロックに関連する一時エラーを記録している場合、レプリケーション SQL スレッドがその後非一時エラーメッセージで終了しないかぎり、レプリカでトランザクションを手動で再起動する必要はありません。
このエラーコード検証動作が望ましくない場合は、--slave-skip-errors オプションでエラーの一部またはすべてを隠す (無視する) ことができます。
MyISAM などの非トランザクションストレージエンジンの場合、テーブルを不完全に更新してエラーコードを返すだけのステートメントが存在する場合があります。 これはたとえば、1 つの行がキー制約に違反する複数行挿入で、または長い更新ステートメントが一部の行を更新したあとに強制終了された場合に発生する可能性があります。 これがソースで発生した場合、レプリカはステートメントの実行結果が同じエラーコードになることを想定しています。 そうでない場合、レプリケーション SQL スレッドは前述のように停止します。
ソースとレプリカで異なるストレージエンジンを使用するテーブル間でレプリケートする場合は、同じステートメントをテーブルの一方のバージョンに対して実行すると異なるエラーが生成される可能性がありますが、他方に対しては生成されないか、一方のバージョンのテーブルでエラーが発生する可能性がありますが、他方のバージョンでは発生しないことに注意してください。 たとえば、MyISAM は外部キー制約を無視するため、ソース上の InnoDB テーブルにアクセスする INSERT または UPDATE ステートメントは外部キー違反を引き起こす可能性がありますが、レプリカ上の同じテーブルの MyISAM バージョンで同じステートメントを実行してもそのようなエラーは発生せず、レプリケーションは停止します。