ファジーチェックポイントと一貫したチェックポイント

チェックポイントは何のためにあるか

WAL（先行書き込みログ） を採る DBMS は、コミット時にデータページを書き戻さず、ログだけを永続化します。速い代わりに、ディスク上のデータページは「いつの時点まで反映されているか」がページごとにバラバラになります。クラッシュリカバリはこの食い違いを WAL の再生（redo）で埋めますが、何の基準点も無ければ DB 開始時点から全ログを redo する羽目になり、ログは無限に伸び、復旧は無限に遅くなります。

これを区切るのが チェックポイント です。チェックポイントは「この LSN 以前の変更はすべてデータページへ反映済み」という保証点を WAL に刻みます。リカバリはその点以降のログだけ見ればよくなり、再生時間が有界になります。同時に、それより古い WAL は（アーカイブ等の用途が無ければ）回収・再利用できます。

チェックポイントの本質は、ダーティページを書き戻すこと「ではなく」、再生開始点を WAL 上に確定してリカバリ範囲を有界化することにある。書き戻しは手段、有界化が目的です。

この目的の達成方法に二つの流儀があり、それが一貫チェックポイントとファジーチェックポイントです。

一貫（consistent / sharp）チェックポイント

最も素直なのは、チェックポイント時にデータベースを一貫した一点へ揃えるやり方です。手順は概念的にこうなります。

1. 新規トランザクションの更新を一時停止（または静止点まで待つ）
2. 実行中の更新がページに反映され切るのを待つ
3. バッファ上の全ダーティページをディスクへ書き戻し、fsync
4. 「checkpoint(LSN=C)」レコードを WAL に書き、fsync
5. 更新を再開

この方式の利点は、リカバリが極めて単純になることです。チェックポイント完了時点でディスク上の全ページが LSN = C まで反映済みと保証されるため、リカバリは C 以降のログだけを redo すれば足り、ダーティページ表のような付帯情報も要りません。「一貫」「sharp（鋭い）」と呼ばれるのは、基準点が時間軸上の一点に集約されるからです。

ファジー（fuzzy）チェックポイント

実用 DBMS が採るのが ファジーチェックポイント です。「ファジー（曖昧）」の名は、チェックポイントの瞬間にデータベースが一貫した一点に揃っていない――どのページがどこまでディスクに着地しているか曖昧なまま進める――ことに由来します。発想を逆転させ、ページの書き戻しを待たずに基準点だけを刻みます。

核心は、平常時にメモリ上で維持される二つの表をスナップショットすることです。

• ダーティページ表（DPT, Dirty Page Table）: 変更済みでまだディスク未着地のページ集合。各エントリは (ページID, recLSN) を持つ。recLSN は「そのページを最初に汚した変更の LSN」で、redo の開始点を決める。
• トランザクション表（TT）: 実行中トランザクションの集合。各エントリは (トランザクションID, 状態, lastLSN) を持つ。

ファジーチェックポイントは、更新を止めずにこの DPT と TT のスナップショットを WAL に書くだけです。ダーティページの実際の書き戻しは、バッファ管理のバックグラウンド書き出し（バッファプールとページ置換）に委ねます。

スナップショット記録中も更新は走り続けるため、チェックポイントの「開始」と「終了」レコードの間に新たな更新が挟まり得ます。リカバリはこの揺らぎを許容する設計になっており、begin_checkpoint と end_checkpoint の双方を見て一貫した起点を再構築します。これが「曖昧でも正しく復旧できる」仕掛けの正体です。

二方式の比較

一貫チェックポイントはリカバリこそ単純ですが、平常時の停止が許容できません。ファジーチェックポイントは平常時を止めない代わりに、リカバリで DPT・TT を再構築する Analysis フェーズ を必要とします。実装の複雑さを復旧側に寄せて平常時を守る、というのが現代 DBMS の選択です。詳しい3フェーズ復旧は ARIES リカバリアルゴリズム を参照してください。

リカバリ時間との関係

リカバリで redo すべきログ量は、おおむね「最後のチェックポイント以降に蓄積したダーティページの変更量」で決まります。ここにチェックポイント間隔が効きます。

チェックポイント間隔を短く → 各時点のダーティ量が少ない → redo が短い → 復旧速い
                          → ただし書き戻し I/O が高頻度 → 平常時スループットが波打つ
チェックポイント間隔を長く → 平常時 I/O は軽い
                          → ダーティ量が溜まり redo が長い → 復旧遅い

つまりチェックポイントは 平常時のコスト と 復旧時間（RTO） のトレードオフを調停するつまみです。ファジー方式でも、書き戻しを短時間に集中させればミニ「一貫チェックポイント」と同じ I/O スパイクを生むため、実装の多くは書き戻しを次のチェックポイントまでの時間に分散（spread checkpoint） し、I/O のピークをならします。PostgreSQL の checkpoint_completion_target はまさにこの分散割合を指定するパラメータです。

試験・実務での要点

まとめ

チェックポイントの目的は、WAL のリカバリ範囲を有界化する基準点を刻むことに尽きます。一貫チェックポイントは更新を止めて全ダーティページを書き戻し、基準点を一点に揃えるためリカバリは単純ですが、バッファ容量に比例して停止が伸びるため実用になりません。ファジーチェックポイントは処理を止めず、DPT と TT のスナップショットだけを記録して書き戻しをバックグラウンドへ分散し、復旧側で Analysis フェーズを担う代わりに平常時を守ります。チェックポイント間隔は復旧時間と平常時コストのトレードオフを握るつまみで、spread checkpoint やダーティ率の上限で I/O スパイクをならすのが要点です。

物理層で永続性を支える土台は WAL の仕組み、ダーティページとバックグラウンド書き出しの実体は バッファプールとページ置換、チェックポイントを起点にした3フェーズ復旧は ARIES リカバリアルゴリズム を合わせて読むと、復旧機構の全体像が立体的に見えてきます。