MySQL シリーズ: redo ログ、undo ログ、binlog の詳細な説明

取引の実施 REDO ログはトランザクションの永続性を保証し、UNDO ログはトランザクションのロールバックと MVCC 機能を支援するために使用されます。 InnoDB ストレージエンジンアーキテクチャ再実行ログ先行書き込みログ戦略トランザクションがコミットされると、最初に REDO ログが書き込まれ、次にページが変更されます。クラッシュによりデータが失われた場合、REDO ログを通じてデータを回復できます。 InnoDBはまずREDOログ情報をREDOログキャッシュに格納します。一定の頻度でログファイルを再実行するために更新する REDO ログファイル: デフォルトでは、InnoDB ストレージエンジンのデータディレクトリに ib_logfile1 と ib_logfile2 という名前の 2 つのファイルがあります。各 InnoDB ストレージエンジンには少なくとも 1 つの REDO ログファイルグループがあり、各ファイルグループには少なくとも 2 つの REDO ログファイルがあります。次の図 1 は、REDO ロググループが循環書き込みモードで実行されていることを示しています。InnoDB ストレージエンジンは最初に ib_logfile1 に書き込み、ファイルの末尾に達すると、REDO ログファイル ib_logfile2 に切り替えます。図 2 に示すように、OS バッファーを追加すると、fsync プロセスを理解しやすくなります。ロググループは、論理的な概念である REDO ロググループと呼ばれます。 InnoDB ストレージエンジンには、実際には 1 つのロググループしかありません。ロググループの最初の REDO ログファイルには、最初の 2 KB に 512 バイトのブロックが 4 つ格納されます。 REDOログバッファがディスクにフラッシュされました次の 3 つの状況が更新されます。マスタースレッドは、1秒ごとにREDOログバッファをREDOログファイルにフラッシュします。各トランザクションがコミットされると、REDOログバッファはREDOログファイルにフラッシュされます。再実行ログバッファプールの残りスペースが1/2未満になると、再実行ログは再実行ログファイルにフラッシュされます。上記の 3 つの状況のうち 2 番目の状況を補足するために、ディスク書き込みプロセスのトリガーは、コミット操作の実行時に REDO ログを処理する方法を示すパラメーター innodb_flush_log_at_trx_commit によって制御されます。パラメータinnodb_flush_log_at_trx_commitの有効な値は0、1、2です。 0 は、トランザクションがコミットされたときに、トランザクションの REDO ログがディスク上のログファイルに書き込まれず、メインスレッドが 1 秒ごとに更新するのを待機することを意味します。 1はコミットの実行時にREDOログバッファをディスクに同期的に書き込むことを意味します。つまり、fsyncの呼び出しを伴います。 2 は、REDO ログを非同期でディスクに書き込む、つまりファイルシステムキャッシュに書き込むことを意味します。コミット時に REDO ログファイルが書き込まれるという保証はありません。 0 の場合、データベースがクラッシュすると、一部のログがディスクにフラッシュされないため、最後の期間のトランザクションが失われます。 2. オペレーティングシステムがクラッシュすると、ファイルシステムキャッシュから REDO ログファイルにフラッシュされていないトランザクションの部分は、データベースの再起動後に失われます。次の図は理解を助ける REDOログブロック InnoDB ストレージエンジンでは、REDO ログは 512 バイトで保存されます。つまり、REDO ログキャッシュと REDO ログファイルはブロック単位で保存され、各ブロックは 512 バイトになります。 REDO ログヘッダーは 12 バイト、REDO ログテールは 8 バイトなので、各 REDO ログブロックには実際には 492 バイトを格納できます。 REDOログ形式 REDO ログはページベースの形式で記録されます。デフォルトでは、InnoDB のページサイズは 16 KB です (innodb_page_size 変数によって制御されます)。ページには多数のログブロック (各 512 バイト) を保存でき、ログブロックにはデータページの変更が記録されます。ログ本体の形式は 4 つの部分に分かれています。 redo_log_type: 1 バイトを占め、REDO ログのログタイプを示します。 space: テーブルスペースの ID を示します。圧縮後、占有スペースは 4 バイト未満になる場合があります。 page_no: 圧縮されたページオフセットを示します。 redo_log_body は各 redo ログのデータ部分を表し、リカバリ中に解析のために対応する関数が呼び出されます。たとえば、挿入ステートメントと削除ステートメントによって REDO ログに書き込まれる内容は異なります。次の図は、挿入と削除の一般的な記録方法を示しています。 REDOログリカバリ次の LSN (ログシーケンス番号) はチェックポイントを表します。データベースが LSN 10000 でクラッシュした場合、回復操作では LSN10000 ～ LSN13000 の範囲のログのみが回復されます。元に戻すログ UNDOログの役割 Undo は、データベースを論理的に元の状態に復元するだけの論理ログです。すべての変更は論理的にキャンセルされますが、ロールバック後にデータ構造とページ自体が異なる場合があります。 UNDO ログには、ロールバックと複数行バージョン制御 (MVCC) の提供という 2 つの機能があります。 InnoDB ストレージエンジンがロールバックすると、各 INSERT に対して DELETE が完了し、各 DELETE に対して INSERT が実行され、各 UPDATE に対して逆 UPDATE が実行されて前の行が戻されます。 MVCC: ユーザーがレコードの行を読み取るときに、そのレコードが他のトランザクションによって占有されている場合、現在のトランザクションは元に戻す操作を通じて前の行のバージョン情報を読み取ることができ、ロックなしの読み取りを実現します。 UNDOログ保存方法 InnoDB ストレージエンジンは、セグメント単位で UNDO を管理します。ロールバックセグメントはロールバックセグメントと呼ばれ、各ロールバックセグメントには 1024 個の UNDO ログセグメントがあります。旧バージョンでは、ロールバックセグメントは 1 つしかサポートされていなかったため、記録できる UNDO ログセグメントは 1024 個だけでした。その後、MySQL 5.5 では 128 個のロールバックセグメント、つまり 128*1024 個の取り消し操作がサポートされるようになりました。また、変数 innodb_undo_logs (バージョン 5.6 より前では、この変数は innodb_rollback_segments でした) を使用してロールバックセグメントの数をカスタマイズすることもできます。デフォルト値は 128 です。 UNDO ログは、デフォルトで共有表領域に保存されます。トランザクションコミットUNDOログ処理トランザクションがコミットされると、InnoDB ストレージエンジンは次の 2 つの処理を実行します。取り消しログは、後で削除するためにリストに入れられます。取り消しログとそれが配置されているページを最終的に削除できるかどうかは、削除スレッドによって決定されます。 UNDO ログが配置されているページが再利用できるかどうかを確認します。再利用できる場合は、次のトランザクションに割り当てます。トランザクションがコミットされると、まず UNDO ログがリンクリストに入れられ、次に UNDO ページの使用済みスペースが 3/4 未満かどうかが判断されます。そうであれば、UNDO ページを再利用できることを意味し、新しい UNDO ログが現在の UNDO ログの後に記録されます。元に戻すログは次のように分かれています: 元に戻すログを挿入元に戻すログを更新トランザクションの分離により、挿入の UNDO ログは他のトランザクションからは見えません。そのため、トランザクションがコミットされた後、パージ操作を必要とせずに UNDO ログを直接削除できます。更新元に戻すログには、削除および更新操作によって生成された元に戻すログが記録されます。 UNDO ログは MVCC メカニズムを提供する必要がある可能性があるため、送信時に削除することはできません。更新には 2 つのケースがあります。日付列が主キー列でない場合は、UNDO ログに逆の順序で更新方法が直接記録されます。つまり、更新は直接実行されます。主キーを更新する操作は、次の 2 つのステップに分けられます。まず、元の主キーレコードを削除済みとしてマークし、TRX_UNDO_DEL_MARK_RECタイプのUNDOログを生成する必要があります。その後、新しいレコードが挿入され、TRX_UNDO_INSERT_MARK_REC タイプの UNDO ログが生成されます。 InnoDB がパージを行う際、最初に履歴リストで UNDO ログを検索し、次に UNDO ページで UNDO ログを検索します。これにより、大量のランダム読み取り操作を回避でき、パージの効率が向上します。 MVCC (マルチバージョン同時実行制御) MVCC は、実際には、レコードの各行の後に 2 つの非表示の列を追加して、作成バージョン番号と削除バージョン番号を記録します。各トランザクションが開始されると、一意の増分バージョン番号が付与されます。 MVCC は、REPEATABLE READ および READ COMMITTED 分離レベルでのみ機能します。コミットされていない読み取りではバージョンの問題は発生せず、シリアル化によってすべての読み取り行がロックされます。例：挿入操作: レコードの作成バージョン番号はトランザクションバージョン番号ですレコードを挿入すると、トランザクションIDは1とみなされ、作成バージョン番号も1になります。

取引の実施

REDO ログはトランザクションの永続性を保証し、UNDO ログはトランザクションのロールバックと MVCC 機能を支援するために使用されます。

InnoDB ストレージエンジンアーキテクチャ

再実行ログ

先行書き込みログ戦略

トランザクションがコミットされると、最初に REDO ログが書き込まれ、次にページが変更されます。クラッシュによりデータが失われた場合、REDO ログを通じてデータを回復できます。

InnoDBはまずREDOログ情報をREDOログキャッシュに格納します。
一定の頻度でログファイルを再実行するために更新する

REDO ログファイル: デフォルトでは、InnoDB ストレージエンジンのデータディレクトリに ib_logfile1 と ib_logfile2 という名前の 2 つのファイルがあります。各 InnoDB ストレージエンジンには少なくとも 1 つの REDO ログファイルグループがあり、各ファイルグループには少なくとも 2 つの REDO ログファイルがあります。

次の図 1 は、REDO ロググループが循環書き込みモードで実行されていることを示しています。InnoDB ストレージエンジンは最初に ib_logfile1 に書き込み、ファイルの末尾に達すると、REDO ログファイル ib_logfile2 に切り替えます。

図 2 に示すように、OS バッファーを追加すると、fsync プロセスを理解しやすくなります。

ロググループは、論理的な概念である REDO ロググループと呼ばれます。 InnoDB ストレージエンジンには、実際には 1 つのロググループしかありません。

ロググループの最初の REDO ログファイルには、最初の 2 KB に 512 バイトのブロックが 4 つ格納されます。

REDOログバッファがディスクにフラッシュされました

次の 3 つの状況が更新されます。

マスタースレッドは、1秒ごとにREDOログバッファをREDOログファイルにフラッシュします。
各トランザクションがコミットされると、REDOログバッファはREDOログファイルにフラッシュされます。
再実行ログバッファプールの残りスペースが1/2未満になると、再実行ログは再実行ログファイルにフラッシュされます。

上記の 3 つの状況のうち 2 番目の状況を補足するために、ディスク書き込みプロセスのトリガーは、コミット操作の実行時に REDO ログを処理する方法を示すパラメーター innodb_flush_log_at_trx_commit によって制御されます。

パラメータinnodb_flush_log_at_trx_commitの有効な値は0、1、2です。

0 は、トランザクションがコミットされたときに、トランザクションの REDO ログがディスク上のログファイルに書き込まれず、メインスレッドが 1 秒ごとに更新するのを待機することを意味します。
1はコミットの実行時にREDOログバッファをディスクに同期的に書き込むことを意味します。つまり、fsyncの呼び出しを伴います。
2 は、REDO ログを非同期でディスクに書き込む、つまりファイルシステムキャッシュに書き込むことを意味します。コミット時に REDO ログファイルが書き込まれるという保証はありません。

0 の場合、データベースがクラッシュすると、一部のログがディスクにフラッシュされないため、最後の期間のトランザクションが失われます。
2. オペレーティングシステムがクラッシュすると、ファイルシステムキャッシュから REDO ログファイルにフラッシュされていないトランザクションの部分は、データベースの再起動後に失われます。

次の図は理解を助ける

REDOログブロック

InnoDB ストレージエンジンでは、REDO ログは 512 バイトで保存されます。つまり、REDO ログキャッシュと REDO ログファイルはブロック単位で保存され、各ブロックは 512 バイトになります。

REDO ログヘッダーは 12 バイト、REDO ログテールは 8 バイトなので、各 REDO ログブロックには実際には 492 バイトを格納できます。

REDOログ形式

REDO ログはページベースの形式で記録されます。デフォルトでは、InnoDB のページサイズは 16 KB です (innodb_page_size 変数によって制御されます)。ページには多数のログブロック (各 512 バイト) を保存でき、ログブロックにはデータページの変更が記録されます。

ログ本体の形式は 4 つの部分に分かれています。

redo_log_type: 1 バイトを占め、REDO ログのログタイプを示します。
space: テーブルスペースの ID を示します。圧縮後、占有スペースは 4 バイト未満になる場合があります。
page_no: 圧縮されたページオフセットを示します。
redo_log_body は各 redo ログのデータ部分を表し、リカバリ中に解析のために対応する関数が呼び出されます。たとえば、挿入ステートメントと削除ステートメントによって REDO ログに書き込まれる内容は異なります。

次の図は、挿入と削除の一般的な記録方法を示しています。

REDOログリカバリ

次の LSN (ログシーケンス番号) はチェックポイントを表します。データベースが LSN 10000 でクラッシュした場合、回復操作では LSN10000 ～ LSN13000 の範囲のログのみが回復されます。

元に戻すログ

UNDOログの役割

Undo は、データベースを論理的に元の状態に復元するだけの論理ログです。すべての変更は論理的にキャンセルされますが、ロールバック後にデータ構造とページ自体が異なる場合があります。

UNDO ログには、ロールバックと複数行バージョン制御 (MVCC) の提供という 2 つの機能があります。

InnoDB ストレージエンジンがロールバックすると、各 INSERT に対して DELETE が完了し、各 DELETE に対して INSERT が実行され、各 UPDATE に対して逆 UPDATE が実行されて前の行が戻されます。

MVCC: ユーザーがレコードの行を読み取るときに、そのレコードが他のトランザクションによって占有されている場合、現在のトランザクションは元に戻す操作を通じて前の行のバージョン情報を読み取ることができ、ロックなしの読み取りを実現します。

UNDOログ保存方法

InnoDB ストレージエンジンは、セグメント単位で UNDO を管理します。ロールバックセグメントはロールバックセグメントと呼ばれ、各ロールバックセグメントには 1024 個の UNDO ログセグメントがあります。

旧バージョンでは、ロールバックセグメントは 1 つしかサポートされていなかったため、記録できる UNDO ログセグメントは 1024 個だけでした。その後、MySQL 5.5 では 128 個のロールバックセグメント、つまり 128*1024 個の取り消し操作がサポートされるようになりました。また、変数 innodb_undo_logs (バージョン 5.6 より前では、この変数は innodb_rollback_segments でした) を使用してロールバックセグメントの数をカスタマイズすることもできます。デフォルト値は 128 です。

UNDO ログは、デフォルトで共有表領域に保存されます。

トランザクションコミットUNDOログ処理

トランザクションがコミットされると、InnoDB ストレージエンジンは次の 2 つの処理を実行します。

取り消しログは、後で削除するためにリストに入れられます。取り消しログとそれが配置されているページを最終的に削除できるかどうかは、削除スレッドによって決定されます。
UNDO ログが配置されているページが再利用できるかどうかを確認します。再利用できる場合は、次のトランザクションに割り当てます。

トランザクションがコミットされると、まず UNDO ログがリンクリストに入れられ、次に UNDO ページの使用済みスペースが 3/4 未満かどうかが判断されます。そうであれば、UNDO ページを再利用できることを意味し、新しい UNDO ログが現在の UNDO ログの後に記録されます。

元に戻すログは次のように分かれています:

元に戻すログを挿入
元に戻すログを更新

トランザクションの分離により、挿入の UNDO ログは他のトランザクションからは見えません。そのため、トランザクションがコミットされた後、パージ操作を必要とせずに UNDO ログを直接削除できます。

更新元に戻すログには、削除および更新操作によって生成された元に戻すログが記録されます。 UNDO ログは MVCC メカニズムを提供する必要がある可能性があるため、送信時に削除することはできません。

更新には 2 つのケースがあります。

日付列が主キー列でない場合は、UNDO ログに逆の順序で更新方法が直接記録されます。つまり、更新は直接実行されます。
主キーを更新する操作は、次の 2 つのステップに分けられます。
まず、元の主キーレコードを削除済みとしてマークし、TRX_UNDO_DEL_MARK_RECタイプのUNDOログを生成する必要があります。
その後、新しいレコードが挿入され、TRX_UNDO_INSERT_MARK_REC タイプの UNDO ログが生成されます。

InnoDB がパージを行う際、最初に履歴リストで UNDO ログを検索し、次に UNDO ページで UNDO ログを検索します。これにより、大量のランダム読み取り操作を回避でき、パージの効率が向上します。

MVCC (マルチバージョン同時実行制御)

MVCC は、実際には、レコードの各行の後に 2 つの非表示の列を追加して、作成バージョン番号と削除バージョン番号を記録します。各トランザクションが開始されると、一意の増分バージョン番号が付与されます。

MVCC は、REPEATABLE READ および READ COMMITTED 分離レベルでのみ機能します。コミットされていない読み取りではバージョンの問題は発生せず、シリアル化によってすべての読み取り行がロックされます。

例：

挿入操作: レコードの作成バージョン番号はトランザクションバージョン番号です

レコードを挿入すると、トランザクションIDは1とみなされ、作成バージョン番号も1になります。

id	名前	バージョンを作成	バージョンを削除
1	テスト	1

更新操作: まず古いバージョン番号を削除済みとしてマークし、バージョン番号を現在のバージョン番号にして、新しいレコードを挿入します。

例えば、トランザクション2は名前フィールドを更新します
テーブルセット名を「新しいテスト」に設定し、ID を 1 に設定します。

元のレコードは削除対象としてマークされ、削除バージョンは2となり、新しいレコードが挿入され、作成バージョンは2となります。

id	名前	バージョンを作成	バージョンを削除
1	テスト	1	2
1	新しいテスト	2

削除操作: トランザクションバージョンを削除バージョン番号として使用します

例えば、トランザクション3はレコードを削除します
id = 1 のテーブルから削除します。

id	名前	バージョンを作成	バージョンを削除
1	テスト	2	3

クエリ操作

次の 2 つの条件を満たすレコードは、トランザクションによって照会できます。

InnoDBは、現在のトランザクションバージョンよりも前のバージョンのデータ行のみを検索します。
削除された行のバージョンは未定義か、現在のバージョン番号より大きいため、トランザクションによって読み取られた行はトランザクションの開始前に削除されていないことが保証されます。

MVCCの利点: ロック競合を減らし、パフォーマンスを向上

バイナリログ

バイナリファイルの概念と機能

バイナリログは、MySQLデータベースを変更するすべての操作を記録します（データは変更されないため、SELECT、SHOWなどは除きます）。

バイナリファイルの主な機能は次のとおりです。

リカバリ: 一部のデータのリカバリにはバイナリログが必要です
レプリケーション: バイナリログをコピーして実行することで、リモートのMySQL (スレーブ) を別のMySQLデータベース (マスター) とリアルタイムで同期します。
監査: ユーザーはバイナリログ内の情報を監査して、データベースにインジェクション攻撃があるかどうかを判断できます。

3つのバイナリファイル形式

MySQL 5.1 では、STATEMENT、ROW、MIX に設定できる binlog_format パラメータが導入されました。

ステートメント: バイナリファイルには、ログの論理 SQL ステートメントが記録されます。
ROW: テーブル行への変更を記録します。 ROW モードが設定されている場合は、同時実行性を高めるために InnoDB トランザクション分離レベルを READ_COMMITTED に設定できます。
MIX: MySQL はデフォルトで STATEMENT 形式を使用してバイナリファイルを記録しますが、場合によっては ROW が使用されます。考えられる状況は次のとおりです。
テーブルのストレージエンジンは NDB であり、テーブルに対するすべての DML 操作は ROW 形式で実行されます。
UUID()、USER()、CURRENT_USER()、FOUND_ROWS()、ROW_COUNT() などの不確実な関数の使用
INSERT DELAYステートメントの使用
ユーザー定義関数の使用
一時テーブルの使用

REDOログとバイナリファイルの違い

(バイナリファイルは、POINT-IN-TIME (PIT) リカバリとマスター/スレーブレプリケーション環境の確立に使用されます。

バイナリファイルには、InnoDB や MyISAM などの他のストレージエンジンのログを含む、MySQL データベースに関連するすべてのログレコードが記録されます。 InnoDB ストレージエンジンの REDO ログには、ストレージエンジン自体に関連するトランザクションログのみが記録されます。
記録される内容は異なります。バイナリログファイルの記録形式を、ユーザーが STATEMENT、ROW、MIXED のいずれに設定しても、トランザクションの特定の操作内容が記録される、つまり論理ログとなります。 InnoDB ストレージエンジンの REDO ログファイルには、各ページに対する物理的な変更が記録されます。
また、書き込み時間ページが異なります。バイナリログファイルは、トランザクションがコミットされる前にのみコミットされます。つまり、この時点でのトランザクションの大きさに関係なく、ディスクに書き込まれるのは 1 回だけです。ただし、トランザクション中は、REDO ログエントリが継続的に REDO ログファイルに書き込まれます。

グループコミット

トランザクションが読み取り専用トランザクションでない場合は、トランザクションがコミットされるたびに fsync 操作を実行して、REDO ログがディスクに書き込まれたことを確認する必要があります。ただし、ディスク fsync のパフォーマンスには限界があります。ディスク fsync の効率を向上させるために、現在のデータベースではグループコミット機能が提供されています。これにより、複数のトランザクションログを一度に更新して、ファイルに確実に書き込むことができます。

InnoDB グループコミットの場合、2 段階の操作が実行されます。

メモリ内のトランザクションに対応する情報を変更し、ログをREDOログバッファに書き込む
fsync を呼び出すと、ログが REDO ログバッファからディスクに書き込まれるようになります。

InnoDB1.2 より前では、バイナリファイルが開かれるとグループコミット機能が失敗します。

バイナリファイルを開いた後の手順は次のとおりです。
1) トランザクションがコミットされると、InnoDBストレージエンジンは準備操作を実行します。
2) MySQLデータベースの上位層がバイナリファイルを書き込む
3) InnoDBはREDOログファイルにログを書き込む

a) メモリ内のトランザクションに対応する情報を変更し、ログをREDOログバッファに書き込みます。b) fsyncを呼び出して、ログがREDOログバッファからディスクに書き込まれるようにします。

MySQL データベースの上位バイナリファイルの書き込み順序が InnoDB トランザクションのコミット順序と一致するように、MySQL は内部的に prepare_commit_mutex ロックを使用します。そのため、他のトランザクションがステップ b) を実行しているときはステップ 3) のステップ a) を実行できず、行コミット機能が失敗します。

解決策はBLGC（バイナリロググループコミット）です

MySQL 5.6 BLGC 実装は 3 つの段階に分かれています。

フラッシュフェーズ: 各トランザクションのバイナリファイルをメモリに書き込む
同期フェーズ: メモリ内のバイナリをディスクに更新します。キューに複数のトランザクションがある場合、バイナリログの書き込みを完了するには 1 つの fsync 操作のみが必要です。これが BLGC です。
コミットステージ: リーダーはストレージエンジン層のトランザクションコミットを順番に呼び出します。InnoDB はすでにグループコミットをサポートしているため、prepare_commit_mutex のロックによって発生するグループコミットの失敗の問題は解決されています。

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

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