MySQL の 3 つの Binlog 形式の概要と分析

1つ。 Mysql Binlog フォーマットの紹介

Mysql binlog ログには、Statement、MiXED、ROW の 3 つの形式があります。

1. ステートメント: データを変更するすべての SQL ステートメントが binlog に記録されます。

利点: 各行の変更を記録する必要がないため、binlog ログの量が削減され、IO が節約され、パフォーマンスが向上します。 (ROW 形式と比較して、パフォーマンスとログボリュームをどれだけ節約できるかは、アプリケーションの SQL 状況によって異なります。通常、ROW 形式で同じレコードを変更または挿入することによって生成されるログの量は、ステートメントによって生成されるログの量よりも少なくなります。ただし、条件付き更新操作、テーブル全体の削除、ALTER TABLE などの操作がある場合、ROW 形式は大量のログを生成します。したがって、ROW 形式のログを使用するかどうかを検討するときは、アプリケーションの実際の状況、生成されるログの量がどれだけ増加するか、およびそれがもたらす IO パフォーマンスの問題を考慮する必要があります。)

デメリット: 実行されたステートメントのみが記録されるため、これらのステートメントをスレーブ上で正しく実行するには、実行中の各ステートメントの関連情報も記録して、すべてのステートメントがマスター上で実行されたときと同じ結果をスレーブ上で得られるようにする必要があります。さらに、MySQL レプリケーションでは、特定の関数などにより、スレーブがマスターと一致することがあり、これにより多くの関連する問題が発生します (sleep() 関数、last_insert_id()、ユーザー定義関数 (udf) など)。

次の関数を使用するステートメントもコピーできません。

* LOAD_FILE()

* UUID()

* ユーザー()

* 見つかった行()

* SYSDATE() (起動時に --sysdate-is-now オプションが有効になっていない限り)

同時に、INSERT ...SELECTはRBRよりも多くの行レベルロックを生成します。

2.行: SQL ステートメントのコンテキスト関連の情報は記録せず、変更されたレコードのみを保存します。

利点: Binlog は、実行された SQL ステートメントのコンテキスト関連の情報を記録する必要はなく、レコードが変更された内容のみを記録する必要があります。したがって、行レベルのログコンテンツには、データ変更の各行の詳細が明確に記録されます。また、ストアドプロシージャ、関数、またはトリガー呼び出しとトリガーが特定の状況で正しくコピーされないという問題も発生しません。

デメリット: 実行されたすべてのステートメントがログに記録されると、各レコード行の変更として記録されるため、大量のログコンテンツが生成される場合があります。たとえば、update ステートメントが複数のレコードを変更する場合、各変更が binlog に記録されるため、大量の binlog ログが発生します。特に、alter table などのステートメントを実行すると、テーブル構造の変更により各レコードが変更されるため、テーブルの各レコードがログに記録されます。

3.Mixedlevel: 上記の 2 つのレベルが混在しています。一般的なステートメントの変更では、ステートメント形式を使用して binlog を保存します。たとえば、一部の関数とステートメントはマスタースレーブレプリケーション操作を完了できないため、行形式を使用して binlog を保存します。MySQL は、実行される特定の SQL ステートメントごとに記録するログ形式を区別します。つまり、ステートメントと行のいずれかを選択します。新しいバージョンの MySQL の行レベルモードも最適化されています。すべての変更が行レベルで記録されるわけではありません。たとえば、テーブル構造が変更されると、ステートメントモードで記録されます。更新や削除など、データを変更するステートメントについては、すべての行に対する変更が記録されます。

2. Binlogの基本構成とフォーマット設定

1. 基本的な準備

MySQL BInlog ログ形式は、MySQL my.cnf ファイルの属性 binlog_format で指定できます。たとえば、次のようになります。

binlog_format = MIXED //binlog ログ形式

log_bin = directory/mysql-bin.log //binlog ログ名

expire_logs_days = 7 // binlog の有効期限のクリーンアップ時間

max_binlog_size 100m //各binlogログファイルのサイズ

2. Binlogログ形式の選択

Mysql はデフォルトでステートメントログ形式を使用しますが、MIXED が推奨されます。

いくつかの特殊な用途では、binlog ログを介してデータの変更を同期するなど、ROWED の使用を検討できます。これにより、関連する操作が大幅に節約されます。バイナリログデータの処理が非常に簡単になり、混合データに比べて解析も非常に簡単になります（もちろん、ログ量の増加によるIOオーバーヘッドが許容範囲内であることが前提です）。

3.mysqlbinlog形式の選択

MySQL のログ形式の選択原則: INSERT、UPDATE、DELETE などの直接テーブル操作を使用する場合、ログ形式は binlog_format の設定に従って記録されます。GRANT、REVOKE、SET PASSWORD などの管理ステートメントを使用する場合は、とにかく SBR モードを使用して記録されます。

三つ。 Mysql Binlog ログ分析

次のように、MysqlBinlog コマンドを使用して特定の mysql ログを表示します。

///

タイムスタンプを 1350355892/*!*/ に設定します。

始める

//*!*/;

# 1643330 で

#121016 10:51:32 サーバー ID 1 end_log_pos 1643885 クエリ thread_id=272571 exec_time=0 error_code=0

タイムスタンプを 1350355892/*!*/ に設定します。

T_test に挿入します。

//*!*/;

# 1643885 で

#121016 10:51:32 サーバー ID 1 end_log_pos 1643912 Xid = 0

専念 /*！*/;

///

1. 物事を始める時間:

タイムスタンプを 1350355892/*!*/ に設定します。

始める

2.sqlイベントの開始点

#at 1643330: イベントの開始点。1643330 バイトから始まります。

3. sqleventが発生した時刻

#121016 10:51:32: はイベントが発生した時刻です。

4.サーバーID

サーバーID 1: マスターのサーバーID

5.sqleventエンドポイントと経過時間、エラーコード

end_log_pos 1643885: イベントの終了ポイントで、1643885 バイトで終わります。

execTime 0: 経過時間

error_code=0: エラーコード

Xid: イベントはコミットされたXAトランザクションを示します

混合ログの説明:

スレーブログ同期プロセス中に、現在などの時間関数の場合、MIXED ログ形式は、対応する unix_timestamp()*1000 時間文字列をログに生成します。スレーブが同期を完了すると、sqlEvent が発生した時間を使用してデータの正確性を確保します。さらに、一部の機能については、スレーブが対応するデータ同期を完了できます。スレーブが状況を認識しない上記の一部の UDF 機能については、これらの Binlog は ROW 形式で保存され、生成された Binlog を使用してスレーブがデータ同期を完了できるようにします。

上記は、MySQL binlog を介してデータ同期を完了するモジュールを開発する前に調査中に蓄積された情報です。間違っている点があればご指摘ください。

要約する

これで、MySQL の Binlog の 3 つの形式の紹介と分析に関するこの記事は終了です。MySQL の Binlog の 3 つの形式の詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: