[中級者向け！] ARIES/Check pointをわかりやすく解説！[ロギングその②]
はじめに
本記事では ARIES 系の Undo/Redo とチェックポイントまでを扱います。
この記事の対象者
・Siloの論文を読んでる人
・トランザクションの研究をする人
目次
- データベースがクラッシュしたとき、ログはどう動く？
- リカバリ方法
- チェックポイント
こちらを読んだ人向けの記事になっています。↓
1. データベースがクラッシュしたとき、ログはどう動く？
メモリの電源が切れてしまった場合、ログからデータベースの状況を復旧しないといけません。一緒にどうやってリカバリを行うのか見てみましょう。
例
T0: r(A) w(A) commit
T1: r(B) w(B) commit
として、赤線の部分でクラッシュしたと仮定します。ディスク上には赤線までのログしかない状況です。
そうすると、ディスク内のデータは、以下の三通りの状況が考えられます。
2. リカバリ方法
1. ログを末尾まで確認し、「start ログはあるが、commit/abort ログが見当たらないトランザクション」を特定し、Active listに追加
この例だとT1がアクティブリストに追加されます。
Active list
クラッシュ時に動いていた未完了トランザクションをまとめたものです。何をUndoすべきか（未完了の処理）を特定し、リカバリの境界線を決めるために用いられます。LSNの昇順に以下の方法で行います。
①start ログを見つけた: そのトランザクションIDをアクティブリストに追加します。
②commit または abort ログを見つけた: その処理は完了しているので、リストから削除します。
③ログの末尾に到達するまで続ける
2. ログを末尾まで確認し、変更後の操作にする
1. LSN 1: Bを 1000 から 950（変更後）にする
2. LSN 4: Bを 2000 から 2050（変更後）にする
3. アクティブリストに追加されたトランザクションを対象に、一番大きいLSN（最新）から小さいLSN（過去）へ向かって遡り、「逆再生」をする
1. LSN 4: Bを 2050 から 2000（変更前）に戻し、ログにCLR(Compensation Log Record）を書き込む
2. スタートしたログを発見したら、アクティブリストから該当トランザクションを削除しEnd ログを書く
End ログはそのトランザクションに関するすべての処理（コミット、または取り消し作業）が完全に完了し、これ以上このトランザクションについて何もする必要がないことを示すログです。
アクティブリストが空になったため、Undoが終了しリカバリが終わります。
CLR（Compensation Log Record）とは？？
いわばUndoをしたという証拠です。これがあるおかげで、リカバリ作業中に再びクラッシュしても、同じ場所を何度もUndoするようなミスを防ぐことができます
3. チェックポイントとは
前回の記事で「ログがあれば、データ本体の更新は急がなくていい」と書きました。
しかし、全く更新しないと、いざPCが壊れた時に「1年前のログから全部やり直し」になってしまい、復旧に数日かかってしまいます。そこで、定期的に「ここまでの分はデータ本体もディスクに書き込んだよ！」という印を付けます。これがチェックポイントです。
一定時間・一定ログ量(「5分おき」や「ログが10MB溜まるたび」など、定期的なチェックポイント時)やメモリ不足(新しいデータを読み込むためのメモリが足りなくなり、古いデータをディスクに追い出すとき)にデータ本体をフラッシュします。
以下のような例で考えます。T0のコミット前にチェックポイントがあり、T1のコミット前にクラッシュしている状況を考えます。この例では、リカバリの範囲(analysis phase, redo phase, undo phase)がチェックポイント以降のLSN 3-5となります。
このようにチェックポイントを用いることで、リカバリ時に読み直すログの量を減らすことができます。なお、Silo では epoch を用いた commit により、このような Undo 処理自体を不要にする設計が採られています。
最後まで読んでくださりありがとうございました！
是非続編も読んでください↓
Discussion