MySQL Undo ログと Redo ログの概要

元に戻すログ

データベース トランザクションが開始される前に、変更されるレコードが Undo ログに保存されます。トランザクションがロールバックされるか、データベースがクラッシュすると、Undo ログを使用して、コミットされていないトランザクションがデータベースに与えた影響を元に戻すことができます。

UNDOログの生成と破棄

Undo ログはトランザクションの開始前に生成されます。トランザクションがコミットされても、Undo ログはすぐには削除されません。InnoDB はトランザクションに対応する Undo ログを削除リストに入れ、バックグラウンド パージ スレッドによってリサイクルされます。
Undo ログは、変更プロセスを記録する論理ログです。たとえば、削除が実行されると、undolog は挿入を記録し、更新が実行されると、undolog は反対の更新を記録します。

UNDOログの保存

UNDO ログはセグメント単位で管理され、記録されます。 InnoDB データ ファイルにはロールバック セグメントが含まれており、このロールバック セグメントには 1024 個の UNDO ログ セグメントが含まれています。 UNDO ログの保存は、次のパラメータ セットによって制御できます。

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

元に戻すログ機能

トランザクションの原子性の実装

Undo Log は、トランザクションのアトミック性を実現するために作成された製品です。トランザクション処理中にエラーが発生した場合、またはユーザーが ROLLBACK ステートメントを実行した場合、MySQL は Undo ログ内のバックアップを使用して、トランザクション開始前の状態にデータを復元できます。

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

Undo ログは、MySQL InnoDB ストレージ エンジンでマルチバージョン同時実行制御を実装するために使用されます。トランザクションがコミットされる前に、Undo ログに以前のバージョンのデータが保存されます。Undo ログのデータは、他の同時トランザクションによるスナップショット読み取り用のデータの古いバージョンのスナップショットとして使用できます。

トランザクション A は手動でトランザクションを開始し、更新操作を実行します。まず、更新によってヒットしたデータが Undo バッファーにバックアップされます。
トランザクション B は手動でトランザクションを開き、クエリ操作を実行します。Undo ログ データを読み取り、スナップショット読み取り用に返します。

やり直しログ

トランザクションで変更されたデータを指します。最新のデータ バックアップが保存される場所 (Redo ログ) は、REDO ログと呼ばれます。

REDOログの生成と解放

トランザクション操作が実行されると、REDO ログが生成されます。トランザクションがコミットされると、生成された REDO ログはログ バッファーに書き込まれますが、トランザクションがコミットされたときにすぐにディスク ファイルに書き込まれるわけではありません。
トランザクション操作のダーティ ページがディスクに書き込まれると、Redo ログの使命は完了し、Redo ログが占めていた領域を再利用できます (上書きされます)。

Redoログの仕組み

Redo Log は、トランザクションの永続性を実現するために作成された製品です。障害発生時にテーブルのibdファイルに書き込まれていないダーティページが存在する状況を防ぐために、MySQLサービスの再起動時にRedoログに基づいてデータを再実行し、ディスクに書き込まれていないトランザクションデータを永続化する機能を実現します。

REDOログ書き込みメカニズム

Redo ログ ファイルの内容は、順次ループでファイルに書き込まれます。ファイルがいっぱいになると、最初のファイルに戻って上書きされます。

write pos は現在のレコードの位置です。書き込み中は後方に移動します。最後のファイルの末尾に書き込んだ後、ファイル 0 の先頭に戻ります。
チェックポイントは消去される現在の位置であり、後方に移動され、循環的に実行されます。レコードを消去する前に、レコードをデータ ファイルに更新する必要があります。
書き込み位置とチェックポイント間の空きスペースは、新しい操作を記録するために使用できます。書き込み位置がチェックポイントに追いついた場合、それは満杯であることを意味します。この時点では、新しい更新は実行できません。チェックポイントを進めるには、停止して一部のレコードを消去する必要があります。

Redoログ関連の設定パラメータ

各 InnoDB ストレージ エンジンには少なくとも 1 つの REDO ログ ファイル グループがあり、各ファイル グループには少なくとも 2 つの REDO ログ ファイル (デフォルトは ib_logfile0 と ib_logfile1) があります。以下のパラメータセットを通じてREDOログの保存を制御できます。

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

RedoバッファをRedoログに永続化するための戦略は、Innodb_flush_log_at_trx_commitを通じて設定できます。

0: 再実行バッファが 1 秒ごとにコミットされ、OS キャッシュにキャッシュがフラッシュされ、ディスクに書き込まれるため、1 秒以内にトランザクション データが失われる可能性があります。この操作は、バックグラウンド マスター スレッドによって 1 秒ごとに実行されます。
1 (デフォルト): トランザクションのコミットごとに、Redo バッファ -> OS キャッシュ -> キャッシュをディスクにフラッシュが実行されます。これは最も安全な方法ですが、パフォーマンスは最も低くなります。
2: トランザクションがコミットされるたびに、Redo バッファ -> OS キャッシュが実行され、その後、バックグラウンドのマスター スレッドが 1 秒ごとに OS キャッシュ -> キャッシュをディスクにフラッシュを実行します。

MySQL がクラッシュしてもデータは失われず、サーバー全体がクラッシュした場合にのみ 1 秒分のトランザクション送信データが失われるため、通常は値 2 を選択することをお勧めします。

以上がMySQL Undo LogとRedo Logの詳細な概要です。MySQL Undo LogとRedo Logの詳細については、123WORDPRESS.COMの他の関連記事に注目してください。