本番環境で使用する前に、MySQLレプリケーションのテストを行っています。私たちの場合、MySQLはPuppetによってセットアップされており、binlog_format設定がマスターとスレーブで異なることに気付きました。
マスター:
mysql> show variables like 'binlog_format' \G
*************************** 1. row ***************************
Variable_name: binlog_format
Value: ROW
スレーブ上:
mysql> show variables like 'binlog_format' \G
*************************** 1. row ***************************
Variable_name: binlog_format
Value: STATEMENT
時々、レプリケーションは次のようなエラーで中断します。
Last_SQL_Error:テーブルtest.pruningでDelete_rowsイベントを実行できませんでした。 「プルーニング」でレコードが見つかりません、Error_code:1032;ハンドラエラーHA_ERR_KEY_NOT_FOUND;イベントのマスターログmysql-bin.000002、end_log_pos 1448
これがマスターとスレーブで異なるbinlog_format設定が原因で発生したのかどうかは、はっきりとはわかりません。
上記のエラーは、この矛盾した設定が原因である可能性がありますか?スレーブを「行」ベースのフォーマットに変更する必要がありますか?エラーを再現するのは難しいので、私たちが従うべきベストプラクティスを探しています。MySQLは非常に初めてです。
受け取ったエラーメッセージ
Last_SQL_Error:テーブルtest.pruningでDelete_rowsイベントを実行できませんでした。 「プルーニング」でレコードが見つかりません、Error_code:1032;ハンドラエラーHA_ERR_KEY_NOT_FOUND;イベントのマスターログmysql-bin.000002、end_log_pos 1448
行ベースのレプリケーションでDELETEクエリを実行すると、このメッセージが表示されることがあります。残念ながら、 これは行ベースのレプリケーションの欠点の1つです :
- 行ベースのレプリケーションの欠点
RBRはログに記録する必要があるより多くのデータを生成できます。 DMLステートメント(UPDATEステートメントやDELETEステートメントなど)をレプリケートするために、ステートメントベースのレプリケーションでは、ステートメントのみがバイナリログに書き込まれます。対照的に、行ベースのレプリケーションでは、変更された各行がバイナリログに書き込まれます。ステートメントが多くの行を変更する場合、行ベースのレプリケーションはバイナリログにかなり多くのデータを書き込む可能性があります。これは、ロールバックされるステートメントにも当てはまります。これは、バックアップの取得と復元にさらに時間がかかる可能性があることも意味します。さらに、バイナリログはデータを書き込むためにより長い時間ロックされるため、同時実行性の問題が発生する可能性があります。
私は似たようなものに対処しました(error 1032
MySQLマスターマスターレプリケーション、両方のマスターの行を削除しても安全ですか? )に対する私の回答では、DELETE
クエリを実行することが問題でした。
あなたの場合、スレーブはSTATEMENT
を使用しているため、行の変更はマスターとスレーブ間のPRIMARY KEYの正確な一致であると予想されます。多くの場合、そうでない場合があります。そのため、エラー1032が存在します。
安全にプレイするには、
MIXED
とスレーブROW
を試すことができます。少なくとも、マスターがSTATEMENT
でない場合は、スレーブでSTATEMENT
を使用しないでください。