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になります。