4.4障害回復とログ

データベースサーバの突然の電源断やディスク障害に備えるDBAにとって、「どのログ方式・チェックポイント間隔・回復手順を採るか」は、耐久性の保証と回復時間（RTO）のバランスを左右する重要な判断です。ログを取りすぎれば書き込みオーバーヘッドが増え、チェックポイントを疎にしすぎれば障害後の回復に時間がかかります。この節では、障害の種別に応じてどの回復方式を適用すべきかを判断する視点を養います。

4.4.1WAL（ログ先書き）の原則

• WAL（Write-Ahead Logging・ログ先書き）＝データベース本体（データページ）への変更を実際にディスクへ反映する前に、その変更内容をログ（更新前ログ・更新後ログ）として先に不揮発性記憶へ書き込んでおく原則。この順序を守ることで、データ本体への反映が完了する前に障害が起きても、ログさえ残っていれば変更内容を再現・取消できるため、耐久性と一貫性の両方を保証する土台になる。
• WALの原則があるからこそ、DBMSはデータ本体への書き込みを遅延させて（バッファリングして）まとめて行うことで書き込み性能を高められる——ログさえ先に確実に書いておけば、データ本体の反映が多少遅れても障害時にログから復元できるため安全性は損なわれない。ログの書き込み自体は追記（シーケンシャルライト）が中心のため、ランダムI/Oが必要なデータページ更新より高速に行える。

4.4.2チェックポイントとUNDO/REDO

• チェックポイント＝ある時点までのログの内容をデータ本体へ確実に反映し、その時点を記録しておく処理。障害回復時は、ログの先頭からではなく直近のチェックポイント以降のログだけを読めばよいため、回復に要する時間を大幅に短縮できる。チェックポイントの間隔を狭めるほど回復は速くなるが、チェックポイント処理自体のI/O負荷が増え通常運用時の性能に影響する。
• 障害回復はUNDO（取消）とREDO（再実行）の組み合わせで行う。REDO＝チェックポイント以降ログに記録されているがデータ本体にまだ反映されていないCOMMIT済み変更をログから再適用する処理（ロールフォワード）。UNDO＝チェックポイント以降に開始されたがCOMMITされていない（障害時点で未完了の）トランザクションの変更を取り消す処理（ロールバック）。多くのDBMSはこの2つを「REDO（前方へ再適用）してからUNDO（未完了分を巻き戻す）」という順で組み合わせる。

ある基幹システムのDBAが、データベースサーバの突然の電源断（システム障害）から復旧する手順を検証しているとします。この障害は、ディスク自体は無事だがメモリ上のバッファ内容が失われるという性質のため、DBAはまず直近のチェックポイントのログ位置を確認し、そこから障害発生時点までのログだけを読み込みます。次に、ログの中からCOMMIT済みだがまだデータ本体（データページ）に反映されていない変更を洗い出し、REDO（再適用）でロールフォワードします——これによりWALの原則（ログが先に書かれている）のおかげで、COMMIT済みの変更が失われずに再現されます。続いて、チェックポイント以降にBEGINしたがCOMMITされないまま障害を迎えたトランザクションを洗い出し、UNDO（取消）でロールバックし、中途半端な更新をデータベースから除去します。ここで陥りやすい誤りは、「REDOとUNDOはどちらから始めても最終的に同じ状態に収束するはずだから順序は問わない」という判断です——UNDOを先に行うと、まだREDOで反映されていないはずの後続のCOMMIT済み変更を誤って巻き戻してしまう恐れがあるため、標準的な回復手順ではREDO（COMMIT済み変更を全て反映し終える）を先に完了させてからUNDO（未完了分の巻き戻し）を行う順序を厳密に守る必要があります。なお、これはディスク自体は無事なシステム障害の回復手順であり、ディスクそのものが壊れる媒体障害の場合はログだけでは復旧できず、バックアップからの復元＋ログによるロールフォワードという別の手順が必要になる点も併せて確認します。

4.4.3この節のまとめ

• WALはデータ本体より先にログを書く原則で、耐久性の保証と書き込み性能向上の土台になる
• チェックポイントは直近以降のログだけ読めばよくする仕組みで回復時間を短縮する
• システム障害はREDO（COMMIT済み変更の再適用）を先に完了させてからUNDO（未完了分の取消）を行う——媒体障害はバックアップ復元が前提