MySQL 8.0 の binlog の詳細な説明

1 はじめに

バイナリログは、データを持つ、またはデータを変更する可能性がある SQL ステートメントを記録し、バイナリ形式でディスクに保存します。

2. Binlogの役割

主な機能: レプリケーション、リカバリ、監査。

3 Binlogを有効にする

3.1 現在のMySQLがbinlogをサポートしているかどうかを確認する

以下のOFFはサポートされていないことを意味します

3.2 binlogをサポートするためにmy.cnfファイルを変更する

my.cnf パスを表示

mysql --help --verbose | grep my.cnf

/etcに新しいファイルmy.cnfを作成し、次の内容を追加します。注: mysqldグループを追加します

MySQLを再起動する

binlogがサポートされているかどうかを再度確認してください

3 つのバイナリログ管理コマンド

マスターログを表示

すべての Binlog ログのリストを表示します。

show master status バイナリログのステータスを表示します。最後の Binlog ログの番号名と最後のイベントが終了した位置 (pos) を表示します。

ログをフラッシュする

binlog ログファイルを更新します。更新後、新しい Binlog ログファイルが作成されます。

マスターをリセット

すべてのbinlogログファイルをクリアする

binlog ログファイルを表示する

mysqlbinlog mysql-bin.000002

4 Binlog関連の変数

ログビン

バイナリログスイッチ。

'log_bin' のような変数を表示します。

変数を表示します:

'log_bin' のような変数を表示します。

バイナリログフォーマット

Binlog ログ形式。

変数を表示:

'binlog_format' のような変数を表示します。

5 Binlogログ形式

行

変更されたレコードの詳細のみが保存され、SQL ステートメントのコンテキスト関連の情報は記録されません。

アドバンテージ

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

欠点

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

声明

データを変更するすべての SQL ステートメントは Binlog に記録されます。

アドバンテージ

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

欠点

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

混合

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

Binlog ログ形式の選択

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

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

mysqlbinlog 形式の選択

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

6 Binlog関連のSQLを表示する

binlog イベントを表示 [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]

最初のBinlogログを表示する

binlog イベントを表示します。

指定されたBinlogログを表示する

'mysql-bin.000001' の binlog イベントを表示します。

指定された場所から開始し、指定されたBinlogログを表示します

666 からの 'mysql-bin.000001' の binlog イベントを表示します。

指定された場所から開始し、指定されたBinlogログを表示し、クエリの数を制限します

666 制限 2 から 'mysql-bin.000001' の binlog イベントを表示します。

指定された位置からオフセットで開始し、指定された Binlog ログを表示し、照会するエントリの数を制限します。

666 制限 1、2 から 'mysql-bin.000001' の binlog イベントを表示します。

7 Binlog列の説明

イベントタイプ

QUERY_EVENT 開始、テーブルの削除、テーブルの切り捨てなど、データに関連しない操作。
TABLE MAP EVENTは、次の操作に対応するテーブル情報を記録し、データベース名とテーブル名を保存します。
XID_EVENTはトランザクションのコミットをマークします
WRITE ROWS EVENTはデータを挿入します。つまり、挿入操作です。
UPDATE ROWS EVENTはデータを更新する、つまり更新操作である
DELETE ROWS EVENTはデータを削除します。つまり、削除操作です。

参照する

https://www.jb51.net/article/197048.htm

要約する

MySQL 8.0 の binlog の詳細な説明に関するこの記事はこれで終わりです。MySQL 8.0 の binlog に関するより詳しい説明については、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

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