概要
という勉強会があるのでその前にRedoログとは？みたいなのを復習しておこうと思ったので書きます
より深く知るには以下の記事がとてもよかったので貼っておきます。
目次
Redoログとは？
データベースにおけるRedoログ
データベースにおけるRedoログは、データベースシステムにおいて重要な役割を果たすログファイルの一種です。Redoログは、データベースの整合性を保ち、クラッシュリカバリ（障害回復）を可能にするための仕組みです。以下にその概要と具体的な役割を説明します。
- トランザクションの追跡
Redoログは、データベース内で行われたすべての変更操作（INSERT、UPDATE、DELETEなど）を記録します。トランザクションがコミットされる前に行われた変更も含まれます。
- 耐久性の確保
Redoログは、データベースがクラッシュした場合でも、最新のトランザクションを再現できるようにするために使用されます。ディスクに書き込まれるため、電源障害やシステムクラッシュが発生しても、ログが失われないようにします。
- リカバリプロセス
データベースがクラッシュした後、Redoログを使用して、クラッシュ前の最後のコミットまでのすべての変更を再適用します。これにより、データの一貫性が保たれます。
Redoログの概念は、MySQLに限らず、多くのリレーショナルデータベース管理システム（RDBMS）で共通して使用されています。OraclやポスグレにもありますしRedisもAOFを実現するためにRedoログがあります。
MySQLにおけるRedoログ
MySQLでは、いくつかのストレージエンジンが使用可能ですが、その中でもInnoDBはデフォルトで使用されることが多く、Redoログを活用しています。InnoDBのRedoログは、トランザクションの変更内容をディスクに永続化する前に記録されるため、システム障害が発生してもトランザクションのデータを復旧することが可能です。
Redoログの仕組み
- ログバッファへの書き込み
トランザクションが実行されると、その変更内容はまず「ログバッファ」に書き込まれます。ログバッファはメモリ上に存在し、高速に書き込みが行われます。
- ディスクへのフラッシュ
一定の条件（例えば、ログバッファがいっぱいになった時やトランザクションがコミットされた時）で、ログバッファの内容がディスクのRedoログファイルに書き込まれます。このディスクへのフラッシュにより、トランザクションの耐久性が保証されます。
- クラッシュリカバリ
もしデータベースがクラッシュした場合、再起動時にRedoログファイルが利用されます。InnoDBはRedoログを読み込み、未完了のトランザクションの変更を再適用（ロールフォワード）することで、データベースの一貫性を回復します。クラッシュリカバリの他のフェーズとかは以下の記事で書いているので見てもらえると。
+-------------------+ +-------------------+ +-----------------------+
| User | | Log Buffer | | Redo Log File (Disk) |
| (Executes | -----> | (In Memory) | -----> | |
| Transactions) | | | | |
+-------------------+ +-------------------+ +-----------------------+
^ ^
| |
+-------+ +---------+
| |
+-------------------+ +------------------------+
| System Crash | | Database Recovery |
| (Failure) | -----> | (Using Redo Log) |
+-------------------+ +------------------------+
redoログファイル
- ログファイルの場所
/mysql/#innodb_redoに格納されています。ファイル名は使用している #ib_redoX と予備用の #ib_redoX_tmpがあります。使い切ると新しい番号のファイルが生成されていきます。
$ ls -l /var/lib/mysql/#innodb_redo/ -rw-r----- 1 mysql mysql 3276800 Aug 5 13:23 '#ib_redo10_tmp' -rw-r----- 1 mysql mysql 3276800 Aug 5 13:23 '#ib_redo11_tmp' -rw-r----- 1 mysql mysql 3276800 Aug 5 13:23 '#ib_redo37_tmp' (省略) -rw-r----- 1 mysql mysql 3276800 Aug 5 13:23 '#ib_redo6' -rw-r----- 1 mysql mysql 3276800 Aug 5 13:23 '#ib_redo7_tmp' -rw-r----- 1 mysql mysql 3276800 Aug 5 13:23 '#ib_redo8_tmp' -rw-r----- 1 mysql mysql 3276800 Aug 5 13:23 '#ib_redo9_tmp'
redo_logのファイルサイズは以下のように取得することもできる
mysql> select * from performance_schema.innodb_redo_log_files; +---------+--------------------------+-----------+----------+---------------+---------+----------------+ | FILE_ID | FILE_NAME | START_LSN | END_LSN | SIZE_IN_BYTES | IS_FULL | CONSUMER_LEVEL | +---------+--------------------------+-----------+----------+---------------+---------+----------------+ | 6 | ./#innodb_redo/#ib_redo6 | 19656704 | 22931456 | 3276800 | 0 | 0 | +---------+--------------------------+-----------+----------+---------------+---------+----------------+
- FILE_ID: RedoログファイルのID。この値はRedoログファイルの番号に対応します。
- FILE_NAME: Redoログファイルのパスとファイル名。
- START_LSN: Redoログファイル内の最初のブロックのログシーケンス番号。
- END_LSN: Redoログファイル内の最後のブロックの次のログシーケンス番号。
- SIZE_IN_BYTES: ファイル内のRedoログデータのサイズ（バイト単位）。データサイズはEND_LSNからSTART_LSNまでの範囲で測定されます。ディスク上のRedoログファイルサイズはファイルヘッダー（2048バイト）のため、わずかに大きくなりますが、この列で報告される値には含まれません。
- IS_FULL: Redoログファイルが満杯かどうかを示します。値が0の場合、ファイルに空き容量があります。値が1の場合、ファイルは満杯です。 CONSUMER_LEVEL: 将来の使用のために予約されています。
MySQL 8.0.30 からは redo ログファイルサイズが動的に変更できるように
MySQL 8.0.30からはREDO ログ容量の動的構成をサポートするようになりました。 このサイズを変えるのはこれまでは再起動が必要だったのですがその場でREDOログファイルのサイズを変更できる新機能になります。とても便利。
innodb_redo_log_capacity システム変数を実行時に設定して、REDO ログ ファイルが占有するディスク領域の合計量を増減できます。 この変更により、REDO ログ ファイルの数とそのデフォルトの場所も変更されました。 MySQL 8.0.30 以降、InnoDB はデータ ディレクトリの #innodb_redo ディレクトリに 32 個の REDO ログ ファイルを保持します。 以前は、InnoDB はデフォルトでデータ ディレクトリに 2 つの REDO ログ ファイルを作成し、REDO ログ ファイルの数とサイズは innodb_log_files_in_group 変数と innodb_log_file_size 変数によって制御されていました。これら 2 つの変数は現在非推奨です。 innodb_redo_log_capacity 設定が定義されている場合、innodb_log_files_in_group および innodb_log_file_size 設定は無視されます。 それ以外の場合、これらの設定は innodb_redo_log_capacity 設定 (innodb_log_files_in_group * innodb_log_file_size = innodb_redo_log_capacity) を計算するために使用されます。これらの変数がいずれも設定されていない場合、REDO ログ容量は innodb_redo_log_capacity のデフォルト値である 104857600 バイト (100MB) に設定されます。 REDO ログおよび REDO ログ容量のサイズ変更操作を監視するために、いくつかのステータス変数が提供されています。 あらゆるアップグレードで通常必要とされるように、この変更ではアップグレード前にクリーン シャットダウンが必要です。
redoログファイルのサイズを監視
8.0.30からMySQL 側での現在の REDO ログ ファイル サイズの監視のためのサーバ変数に対応するステータス変数Innodb_redo_log_resize_statusというのがあります。これを監視することでサイズを見ることができます。
関連する設定
- innodb_flush_log_at_trx_commit
トランザクションコミット時にRedoログをディスクにフラッシュする頻度を指定します。
- innodb_log_buffer_size
Redoログバッファのサイズを指定します。大きなトランザクションがある場合、ログバッファを大きくすることでディスクへの書き込み回数を減らし、パフォーマンスを向上させることができます。
- innodb_flush_method
ディスクへのデータフラッシュ方法を指定します。ディスクI/Oのパフォーマンスに影響を与えるため、システムの設定に応じて適切な値を選ぶことが重要です。
- innodb_log_checksums
Redoログのチェックサム検証を有効にすることで、ログの整合性を保証します。データの信頼性を向上させるために推奨されます。
- innodb_log_compressed_pages
Redoログに書き込まれるページを圧縮するかどうかを指定します。圧縮により、Redoログのサイズが削減され、ディスクI/Oの負担が軽減されます。
Redoログは無効化できる
dump & restoreのテストとかでクラッシュしてもいいようなケースではRedoログは不要という場合にはオフにすることでwriteを早くすることができます。
xtrabackupでの活用
Percona XtraBackupは、MySQLのバックアップおよびリカバリプロセスにおいてRedoログを利用します。XtraBackupは、バックアップ中にデータベースが変更される可能性があるため、Redoログをキャプチャします。これにより、バックアップが一貫性のある状態で取得されます。
checkpoint
データベース管理システムにおいて、データの一貫性と耐久性を確保するための重要なメカニズムの一つが「チェックポイント」です。MySQLのInnoDBストレージエンジンでは、チェックポイントがデータベースのパフォーマンスと信頼性に大きな影響を与えます。チェックポイントは、データベースのバッファプールにある変更データをディスクにフラッシュし、データベースの整合性を保つためのメカニズムです。チェックポイントが発生することで、システムクラッシュ時のリカバリが迅速かつ一貫性のあるものとなります。
チェックポイントの役割
- データの永続性の確保
- データベースのバッファプールに保持されているデータ変更を定期的にディスクに書き込むことで、データの永続性を確保します。
- リカバリ時間の短縮
- バッファプールの管理
- バッファプールの使用効率を高めるため、古いページをディスクにフラッシュし、バッファプールに新しいページをロードできるようにします。
MySQLにおけるチェックポイントは、データの一貫性と耐久性を保ち、システムクラッシュ時のリカバリを迅速にするための重要なメカニズムです。チェックポイントの頻度やタイミングを適切に管理することで、データベースのパフォーマンスと信頼性を最適化することができます。データベース管理者は、チェックポイント関連の設定を理解し、システムの要件に応じて適切に調整することが重要です。
まとめ
この記事が、MySQLにおけるRedoログの理解を深める一助となれば幸いです。質問やご意見がありましたら、ぜひコメント欄やXでお知らせください。
