web-dev-qa-db-ja.com

MySQL v5.1.73-binlog_formatのマスターとスレーブの間に違いはありますか?

本番環境で使用する前に、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は非常に初めてです。

4
Sam

受け取ったエラーメッセージ

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 1032MySQLマスターマスターレプリケーション、両方のマスターの行を削除しても安全ですか? )に対する私の回答では、DELETEクエリを実行することが問題でした。

あなたの場合、スレーブはSTATEMENTを使用しているため、行の変更はマスターとスレーブ間のPRIMARY KEYの正確な一致であると予想されます。多くの場合、そうでない場合があります。そのため、エラー1032が存在します。

安全にプレイするには、

  • マスターとスレーブの両方で binlog_format = ROWを使用します
  • binlog_format = MIXEDをマスターとスレーブの両方で使用します
  • マスターとスレーブの両方で binlog_format = STATEMENTを使用します
  • マスターMIXEDとスレーブROWを試すことができます。少なくとも、マスターがSTATEMENTでない場合は、スレーブでSTATEMENTを使用しないでください。
2
RolandoMySQLDBA