回復とロギング

回復およびロギング機構は、ログに変更を記録することでトランザクションのアトミック性と永続性を保証し、クラッシュ後にコミットされた作業をやり直し、未コミットの作業を元に戻すことを可能にします。

Definition

データベース回復とは、障害後にデータベースを一貫性のある状態に復元するプロセスであり、コミットされたトランザクションの効果が永続的であることを保証し、アボートされたトランザクションや処理中のトランザクションが痕跡を残さないようにします。ロギングとは、これを可能にするために、トランザクションの動作を永続的なログに記録する技術です。

Scope

このトピックでは、データベースが障害からどのように復旧するかについて説明します。具体的には、先行書き込みロギング（WAL）プロトコル、アンドゥおよびリドゥ情報、回復作業の範囲を定めるチェックポイント、および標準的な回復アルゴリズム（特にARIES）とその分析、リドゥ、アンドゥのパスについて扱います。また、ロギングの必要性を決定するバッファ管理ポリシー（スティール/ノースティール、フォース/ノーフォース）についても論じます。通常の運用中に実行される並行性制御プロトコルや分散コミットは、関連するトピックではありますが、この範囲には含めません。

Core questions

• なぜ、ログレコードはそれが記述するデータよりも先に永続ストレージに到達しなければならないのですか（先行書き込みロギング）？
• アンドゥとリドゥは、クラッシュ後の一貫性のある状態をどのように復元しますか？
• バッファ管理ポリシー（スティール/フォース）は、ロギング要件をどのように決定しますか？
• チェックポイントは、回復時間の範囲を定める上でどのような役割を果たしますか？
• ARIESアルゴリズムは、回復を分析、リドゥ、アンドゥにどのように構造化していますか？

Key concepts

• 先行書き込みロギング (WAL)
• アンドゥおよびリドゥロギング
• ログシーケンス番号
• チェックポイント
• スティール/ノースティールおよびフォース/ノーフォースポリシー
• 補償ログレコード
• 分析、リドゥ、アンドゥパス
• ARIES

Key theories

先行書き込みロギング

WALプロトコルは、変更を記述するログレコードが、対応するデータページよりも先に安定ストレージに強制的に書き込まれることを要求します。これにより、クラッシュ後、システムは未コミットの変更をアンドゥし、コミットされた変更をリドゥするために十分な情報を確実に持つことができます。

アンドゥ/リドゥ回復とバッファポリシー

システムがアンドゥ、リドゥ、またはその両方を必要とするかどうかは、バッファポリシーに依存します。スティールポリシー（未コミットのページをディスクに書き込む）はアンドゥを必要とし、ノーフォースポリシー（コミット時にコミットされたページを強制的に書き込まない）はリドゥを必要とします。一般的なスティール/ノーフォースの組み合わせは両方を必要とします。

ARIES

ARIESは、先行書き込みロギング、ログシーケンス番号、および補償ログレコードを用いた3パス（分析、リドゥ、アンドゥ）アルゴリズムを使用して、きめ細かいロックと部分的なロールバックをサポートする、広く採用されている回復手法です。

Clinical relevance

回復とロギングは、永続性を現実のものにします。これらは、システムが支払いなどのトランザクションや注文を一度確認すると、その事実が電力損失やクラッシュ後も存続し、トランザクションの途中でクラッシュが発生しても、データベースが半更新された矛盾した状態になることがないことを保証します。

History

HärderとReuterによる1983年の調査は、トランザクション指向の回復とバッファポリシーの分類の原則を確立しました。IBMのC. Mohanらが開発し、1992年に発表されたARIESは、事実上の標準的な回復アルゴリズムとなり、先行書き込みロギングとログシーケンス番号、補償レコードを組み合わせて、きめ細かいロックをサポートしました。

Key figures

• C. Mohan
• Jim Gray
• Theo Härder
• Andreas Reuter

Seminal works

• mohan1992
• haerder1983
• gray1992

Frequently asked questions

なぜ先行書き込みロギングが必要なのですか？

データベースは、トランザクションがコミットされる前に変更されたページをディスクに書き込む可能性があり、あるいはクラッシュ時にコミットされたページをメモリに保持している可能性があるためです。データページよりも先にログレコードを強制的に書き込むことで、バッファマネージャが何を行ったとしても、回復は未コミットの変更をアンドゥし、コミットされた変更をリドゥして一貫性のある状態に到達するために十分な情報を確実に持つことができます。

チェックポイントは何を達成しますか？

チェックポイントは、定期的にアクティブなトランザクションを記録し、管理情報をログにフラッシュすることで、回復に最近の既知の良好な開始点を提供します。チェックポイントがない場合、回復はログ全体を最初からスキャンする必要があるかもしれません。チェックポイントは、回復がどれだけ遡って処理しなければならないかの範囲を定め、再起動時間を管理可能なものに保ちます。