ログ先行書き込み（WAL）と障害回復（REDO/UNDO・チェックポイント）

障害回復では、確定した更新を失わないことと、未確定の更新を確定したように見せないことを守ります。WALは更新ログをデータページより先に永続化する原則です。REDO・UNDOを区別するときは、問題が仮定するバッファ管理と回復方式を最初に確認します。

WALの原則とコミット通知

メモリで更新したページがまだデータファイルへ書かれていない状態をダーティページと呼びます。データページを永続化する前に、その更新の回復に必要なログを永続化しておけば、中途半端なディスク状態からも回復できます。必要なログを一律に「UNDOログ」と呼んではいけません。更新内容のREDO情報、更新前情報などは回復方式によって異なります。

同期的な耐久性を保証する設定では、コミットの確定に必要なログを永続化してから成功を通知します。データページすべてをその場で書く必要はありません。非同期コミットなどの設定では成功通知後の損失可能性が変わるため、設定を含めて耐久性の範囲を確認します。

REDOとUNDOはバッファ管理で必要性が変わる

教科書的なSTEAL/NO-FORCEのREDO/UNDOモデルでは、確定済み更新を再適用し、未確定更新を取り消します。ARIES方式では、分析後に履歴を繰り返すREDOを行ってから未完了トランザクションをUNDOするため、REDO対象を「コミット済みだけ」と考えると不正確です。

PostgreSQLのクラッシュ回復はWALを再生し、MVCCの可視性によって未確定トランザクションの行を見せません。一般的な物理UNDOを同じ形で行う実装ではありません。試験の抽象モデルと製品固有の動作を混同しないようにします。

チェックポイントが意味すること

チェックポイントは、回復に必要な状態を記録し、更新ページの書出しを進めて、再起動時にさかのぼるログ量を抑える仕組みです。処理中にも更新が続く方式では、チェックポイント開始と終了の間に書かれた更新をすべて反映済みとみなすことはできません。回復開始位置やページごとの状態は方式に依存します。

「最新チェックポイント以前のログなら全部削除できる」とは限りません。進行中トランザクション、バックアップ、PITR、レプリケーションなどのために必要なログがあり得ます。短い間隔は回復時間を抑える一方、書込みやI/Oを増やすことがあるため、運用負荷と復旧目標を比較します。

クラッシュ回復とメディア回復・PITR

クラッシュ回復は、データとログが残っている状態で不整合を修復します。媒体が壊れた場合は、利用可能なバックアップと別媒体などに保管したログから復元します。レプリカがあっても、誤DELETEが複製される場合があるためバックアップの代わりにはなりません。

PITRはベースバックアップを復元し、そのバックアップから目標時点まで連続したログを適用して停止します。任意の過去へ自由に戻せるわけではなく、保持するバックアップとログの範囲が上限です。ログが途中で欠けたらそこを越えて再生できません。復元環境で対象時点と業務データを確認してから切り替えます。

演習1：抽象モデルで回復を分類する

条件：STEAL/NO-FORCEを使う単純なREDO/UNDOモデル。チェックポイント以前の確定更新は反映済み。T1はその前に確定、T2は後に確定し未反映の可能性があり、T3は未確定で書出しの可能性がある。

問い：各トランザクションに必要な回復を分類しよう。

解答例：T1は対象外、T2はREDO、T3はUNDO。

根拠：前提が指定されたモデルでの答え。ARIESやPostgreSQLの全処理へそのまま一般化しない。

演習2：PITRの必要条件

条件：昨日のバックアップから、今朝の誤削除直前へ戻したい。

問い：ログについて必要な条件を説明しよう。（35字以内）

解答例：バックアップから目標時点までのログを連続して保持する。（27字）

根拠：最新ログだけでは途中の更新を再生できない。

復習で確かめること

例の数値や業務条件を変えて同じ結論になるか確認してください。用語の定義だけでなく、問題文のどの条件から、どの制約・SQL・対策を選んだのかを自分の言葉で説明できれば、次の過去問に進みます。

出典と仕様を確認する

IPA：DBシラバス Ver.4.1

PostgreSQL 18：WALの基本

PostgreSQL 18：チェックポイント

PostgreSQL 18：継続アーカイブとPITR

関連するテーマ

トランザクションACID特性とロック機構・デッドロック回避の設計

データベースレプリケーションと高可用性設計（アクティブ/スタンバイ）