MySQLのREDOログ（リドゥログ）とロールバックログ（アンドゥログ）の詳しい説明

序文：

前回の記事では、MySQL システムでよく使用されるログをいくつか説明しました。実は、トランザクション関連のログ、REDO ログ、UNDO ログがありますが、これらはまだ紹介されていません。他のログと比較すると、REDO ログと UNDO ログはより神秘的で観察が困難です。本稿では、主にこれら2種類のトランザクションログの機能と運用・保守方法について紹介します。

1. ログの再実行

トランザクションの 4 つの主要な特性の 1 つが永続性であることは誰もが知っています。具体的には、トランザクションが正常に送信される限り、データベースに加えられた変更は永続的に保存され、いかなる理由でも元の状態に戻すことはできません。では、MySQL はどのようにして一貫性を確保するのでしょうか?最も簡単な方法は、トランザクションがコミットされるたびに、トランザクションに関係するすべての変更されたデータページをディスクに更新することです。ただし、そうすると、主に次の 2 つの点で重大なパフォーマンス上の問題が発生します。

Innodb はページ単位でディスクとやり取りし、トランザクションではデータページ内の数バイトしか変更されない可能性があるため、この時点でデータページ全体をディスクにフラッシュするとリソースの無駄になります。
トランザクションでは複数のデータページの変更が必要になる場合がありますが、これらのデータページは物理的に連続していないため、ランダム IO 書き込みを使用するとパフォーマンスが低下します。

そのため、MySQL は、トランザクションによってデータページに加えられた変更のみを記録する redo ログを設計しました。これにより、パフォーマンスの問題を完全に解決できます (相対的に言えば、ファイルは小さくなり、シーケンシャル IO になります)。

REDO ログは、メモリ内のログバッファ (REDO ログバッファ) と、ディスク上のログファイル (REDO ログファイル) の 2 つの部分で構成されます。 MySQL は DML ステートメントを実行するたびに、まずレコードを REDO ログバッファに書き込み、次に特定の時点で複数の操作レコードを REDO ログファイルに書き込みます。

デフォルトでは、REDO ログはディスク上で ib_logfile0 と ib_logfile1 という名前の 2 つの物理ファイルによって表されます。 REDO ログ関連のパラメータについて簡単に説明します。

innodb_log_files_in_group: ib_logfile0、iblogfile1...iblogfilen という名前が付けられた REDO ログファイルの数。デフォルトは 2 で、最大値は 100 です。
innodb_log_file_size: 単一の REDO ログファイルのサイズを設定します。デフォルト値は 48 MB で、最大値は 512 GB です。最大値は REDO ログファイルシリーズ全体の合計を指すことに注意してください。つまり、(innodb_log_files_in_group * innodb_log_file_size) は最大値の 512 GB を超えることはできません。
innodb_log_group_home_dir: REDO ログファイルグループが配置されているパスを指定します。デフォルト値は ./ で、データベースデータディレクトリ内にあることを意味します。
innodb_log_buffer_size: REDO ログバッファサイズ、デフォルトは 16M。トランザクションログのディスクへの書き込みを遅延し、REDO ログをバッファーに格納してから、innodb_flush_log_at_trx_commit パラメーターの設定に従ってバッファーからディスクにログをフラッシュします。
innodb_flush_log_at_trx_commit: REDO ログをディスクにフラッシュする戦略を制御します。デフォルト値は 1 です。値が 1 の場合、各コミットは REDO ログバッファからシステムに REDO ログを書き込み、それをディスクファイルに fsync します。値が 2 の場合、MySQL はトランザクションがコミットされるたびに、REDO ログバッファーからシステムにログを書き込みますが、書き込み先はシステム自体によってディスクファイルに fsync されるファイルシステムバッファーのみです。データベースインスタンスがクラッシュしても、REDO ログは失われません。ただし、サーバーがクラッシュすると、ファイルシステムバッファはディスクファイルに fsync する時間がないため、この部分のデータは失われます。値が 0 の場合、トランザクションがコミットされたときに redo ログが書き込まれないことを示します。この操作はマスタースレッドでのみ完了し、マスタースレッドでは redo ログの fsync 操作が 1 秒ごとに 1 回実行されます。そのため、インスタンスがクラッシュした場合、最大で 1 秒以内のトランザクションが失われます。

REDO ログとそのバッファサイズを変更するには、データベースインスタンスを再起動する必要があります。初期化中に評価を行うことをお勧めします。特にデータベースインスタンスが頻繁に更新される場合は、REDO ロググループの数とサイズを適切に増やすことができます。ただし、REDO ログサイズを大きくしすぎることはお勧めしません。

2. 元に戻すログ

UNDO ログは主にデータの原子性を保証するために使用されます。トランザクションが発生する前のデータのバージョンを保存し、ロールバックに使用できます。たとえば、INSERT ステートメントには対応する DELETE の UNDO ログがあり、各 UPDATE ステートメントには反対の UPDATE の対応する UNDO ログがあるため、エラーが発生した場合に、データをトランザクション前の状態にロールバックできます。同時に、UNDO ログは MVCC (マルチバージョン同時実行制御) の実装の鍵でもあります。

MySQL 5.7 では、UNDO ログはデフォルトで共有テーブルスペース ibdata に保存されます。初期化中にパラメータを設定することで、別のファイルに変更することもできます。次に、UNDO ログに関連するパラメータをいくつか示します。

innodb_max_undo_log_size: UNDO テーブルスペースファイルの最大サイズを制御します。innodb_undo_log_truncate が有効な場合、UNDO テーブルスペースが innodb_max_undo_log_size しきい値を超えた場合にのみ切り捨てが試行されます。デフォルト値は 1G で、切り捨て後のデフォルト値は 10M です。
innodb_undo_tablespaces: 独立した UNDO 表領域の数を 0 から 128 の範囲で設定します。バージョン 5.7 のデフォルト値は 0 で、独立した UNDO 表領域が有効になっていないことを意味します。このパラメータは、MySQL インスタンスを最初に初期化するときにのみ指定できます。
innodb_undo_directory: UNDO 表領域のストレージディレクトリ (デフォルトのデータディレクトリ) を設定します。
innodb_undo_log_truncate: UNDO テーブルスペースが自動的に切り捨てられ、リサイクルされるかどうかを設定します。このパラメータが有効になるための前提は、独立した表領域が設定されており、独立した表領域の数が 2 以上であることです。

UNDO ログ関連のパラメータはほとんど変更されません。 MySQL 8.0 では、デフォルトで独立した表領域が有効になっているため、UNDO ログ表領域のサイズ設定がより柔軟になる可能性があります。

要約:

この記事は主にREDOログとUNDOログの役割と関連するパラメータ設定について紹介します。この記事は急いで書いたものです。間違いがあれば、メッセージを残して指摘してください。これら 2 種類のログのより深い内容については、おそらく著者はまだ、より徹底的に書く能力が十分ではないのでしょう。さて、MySQL関連のログについての記事を2つ書きました。何か参考になれば幸いです。

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