WAL（先行書き込みログ）の仕組み

なぜ「ログを先に書く」のか

トランザクションの永続性（Durability）は「コミットしたら障害でも消えない」を意味します。素直に実現するなら、コミットのたびに変更したデータページをすべてディスクへ書き戻せばよさそうです。しかしこれは2つの理由で破綻します。

1. ランダム I/O が遅い: 更新したページはディスク上で散らばっており、毎コミットでそれらを fsync（OS のページキャッシュを実デバイスまで確実に書き込む同期）するのは、ランダム書き込みの嵐になります。
2. 部分書き込みで壊れる: ページの書き戻し途中で電源が落ちると、ページが半分だけ更新された torn page（破れたページ）になり、リカバリの手がかりすら失われます。

そこで採るのが WAL（Write-Ahead Logging、先行書き込みログ） です。規律はただ一つ。

データページを永続ストレージへ書き戻すより前に、そのページに対する変更を記述したログレコードを永続化しておく。

ログは追記専用なのでシーケンシャル書き込みになり、ランダムなページ書き戻しよりはるかに速く fsync できます。コミット時に永続化すべきは「散らばったデータページ」ではなく「連続したログの末尾まで」だけになる、これが WAL の本質的な利得です。

LSN とログレコード

各ログレコードには単調増加する LSN（Log Sequence Number、ログ列番号） が振られます。LSN は実質的に「ログ上の書き込み位置（オフセット）」であり、順序と位置を同時に表します。

各データページのヘッダには、そのページに最後に適用された変更の LSN（pageLSN）が記録されます。この一点が Write-Ahead 規則を機械的に実行可能にします。バッファ管理が汚れたページを書き戻す直前に、flushedLSN >= page.pageLSN を確認すればよいのです。満たさないなら、先にログをそこまで fsync してからページを書く。こうして「データより先にログ」が常に成立します。

ログレコードは典型的に redo 情報（やり直しに必要な新しい値や操作）と undo 情報（取り消しに必要な旧い値や逆操作）を持ちます。redo はコミット済み変更の再現に、undo は未コミット変更の巻き戻しに使われます。

クラッシュリカバリはどう保証されるか

クラッシュ後、ディスク上のデータページは「いつの時点まで反映されているか」がページごとにバラバラです。あるページはコミット前の更新まで書かれ、別のページはコミット済み更新がまだ書かれていない、という状態が普通に起こります。WAL を使ったリカバリは、これをログから決定的に修復します。

ここで効くのが 冪等性です。redo はページの pageLSN を見て「そのログの LSN 以下なら適用済み」と判断し、二重適用を避けます。だからリカバリ自体が途中でまた落ちても、最初からやり直して同じ正しい結果に収束します。コミット済みは必ず再現され（redo）、未コミットは必ず消える（undo）。これが WAL によるクラッシュリカバリ保証の核心です。

チェックポイント――ログ再生を無限に伸ばさない

WAL だけだと、リカバリ時に「DB 開始時点から全ログを redo」する羽目になり、ログは無限に伸び、復旧は無限に遅くなります。これを区切るのが チェックポイント です。

チェックポイントは、その時点でバッファ上の汚れたページを実際にディスクへ書き戻し、「ここまではデータページに反映済み」という基準点をログに刻みます。リカバリは原則として最後のチェックポイント以降のログだけを見ればよくなり、再生時間が有界になります。同時に、それより古い WAL は（アーカイブ等の用途がなければ）回収・再利用できます。

fsync とグループコミットの原理

コミットの待ち時間を最終的に決めるのは、コミットログを fsync し終えるまでの時間です。fsync はストレージへの物理的な同期であり、1 回あたり数百マイクロ秒〜ミリ秒級。コミットごとに律儀に 1 回ずつ呼ぶと、fsync のレイテンシがそのままスループットの上限になります。

これを破るのが グループコミットです。短い時間窓の間に到着した複数トランザクションのコミットログをログバッファ上でまとめ、1 回の fsync で一括して永続化します。N 件をまとめれば fsync 回数が N 分の 1 になり、高並行下のスループットが劇的に上がります。各トランザクションは「自分のコミット LSN まで flushedLSN が進んだ」のを待ってから完了応答するため、まとめても永続性は損なわれません。

個別コミット:  T1 → fsync, T2 → fsync, T3 → fsync   （fsync 3 回）
グループコミット: T1,T2,T3 のコミットログを連結 → fsync 1 回で全員確定

ARIES への橋渡し

ここまでの「LSN・pageLSN・redo/undo・チェックポイント・解析/再実行/巻き戻しの3フェーズ」は、そのまま ARIES（Algorithm for Recovery and Isolation Exploiting Semantics）というリカバリ手法の骨格です。ARIES はこれに2つの強力な発想を加えます。

• Repeating History（履歴の再現）: redo フェーズで、未コミットだったトランザクションの操作も含めてクラッシュ直前の状態を一旦すべて再現し、その後で undo する。これにより、リカバリ中にまた落ちても状態が一貫し、復旧の再開が単純になります。
• CLR（Compensation Log Record、補償ログ）: undo で取り消した操作も「取り消したという事実」をログに残します。これにより、undo の最中にクラッシュしても同じ undo を二度実行しない。リカバリ全体が完全に冪等になります。

ARIES は「No-Force / Steal」を前提にします。No-Force はコミット時にデータページの書き戻しを強制しない（だから速い、redo が要る）、Steal は未コミットの汚れたページもバッファ都合で書き戻してよい（だから undo が要る）。WAL はこの自由を安全に成立させる土台そのものです。

まとめ

WAL の発想は「データより先にログを書く」という一行に集約されますが、そこからコミットの高速化（シーケンシャル書き込み＋グループコミット）、復旧の保証（redo/undo の冪等な3フェーズ）、再生範囲の有界化（チェックポイント）が一貫した原理で導けます。並行制御の側面（ロックと MVCC や分離レベル）と組み合わせて初めて ACID 全体が成立する、その「D」と「A」を物理層で支えているのが WAL です。