Write-Ahead Log（WAL、先行書き込みログ）は、データファイルを変更する前に、復旧に必要な変更記録を永続化する方式です。
コミットのたびに大きなデータページ全体を書き出さなくても、先にWALを安全な記憶装置へ書けば、クラッシュ後に未反映の変更を再実行できます。
「ログを先に書く」という順序
PostgreSQLのWALでは、基本的に次の順序を守ります。
- メモリ上で変更に対応するWALレコードを作る
- コミットに必要なWALを永続ストレージへflushする
- コミット成功を返す
- 変更済みのデータページは後でデータファイルへ書ける
もし4の前にプロセスやOSが停止しても、再起動時にWALを読み、コミット済みの変更をデータページへREDOできます。WALより先にデータページだけを書き、必要なログが失われる順序は避けます。
実際の永続性はDB設定、OS、ストレージがflush要求を正しく扱うことにも依存します。fsyncや同期コミットを無効にすれば速く見えても、障害時にコミット済みと通知したデータを失う範囲が変わります。
コミットとdurability
WALへ書いたことと、永続ストレージへflushされたことは区別します。メモリやOSキャッシュにあるだけのWALは、電源断で失われる可能性があります。DBは複数トランザクションのflushをまとめるgroup commitにより、各トランザクションが個別にI/Oする負担を減らせます。
同期設定を緩める判断は、「性能が上がるか」だけでなく「成功応答後に何秒分のトランザクションを失い得るか」で評価します。決済や注文確定と、一時キャッシュの更新では同じ設定が適切とは限りません。
LSNとチェックポイント
WAL内の位置はLSN（Log Sequence Number）などの連続した番号で識別されます。データページ側にも、どこまでのWALが反映されたかを判断する情報があります。
チェックポイントは、その時点までの変更済みデータページを書き出し、復旧開始位置を進める処理です。チェックポイントがなければ、再起動時に非常に古いWALから追う必要があります。
WAL: LSN 100 -> 101 -> 102 -> 103 -> 104
checkpoint ^
recovery starts near this point and replays later required records
頻繁すぎるチェックポイントは書き込みI/Oを集中させ、間隔が長すぎるとWAL量と復旧時間が増えます。製品の既定値を根拠なく変更せず、WAL生成量、checkpoint時間、復旧目標を観測します。
チェックポイントが完了しても、その時点より後のWALは復旧に必要です。ログファイル名や更新日時だけを見て手動削除せず、DBが再利用・削除できる条件を管理機能で確認します。
REDOとUNDOを混同しない
PostgreSQLのクラッシュ復旧は、WALを使ったroll-forward（REDO）が中心です。未コミットの行はMVCCの可視性により見えません。一方、別のDBエンジンやARIES系の説明では、REDOとUNDOを組み合わせることがあります。
「WALには必ずSQL文がそのまま入り、未コミット操作を逆向きに実行する」と一般化できません。物理ログ、論理ログ、その組み合わせなど記録形式は製品で異なります。
PostgreSQLで確認する項目
設定例をコピーする前に、現在値と運用目的を確認します。
SHOW wal_level;
SHOW synchronous_commit;
SHOW checkpoint_timeout;
wal_levelは復旧・レプリケーションなどに必要な情報量へ影響します。synchronous_commitはコミット応答とWALの同期方法へ影響します。値の意味はバージョンと構成に応じて公式文書を確認します。
WALアーカイブやストリーミングレプリケーションは、WALを別目的にも利用する仕組みです。しかし、レプリカがあることと、削除・破損・運用ミスから復元できるバックアップがあることは同じではありません。
レプリケーションと時点復旧
PostgreSQLはWALをスタンバイへ送り、同じ変更を再生できます。また、ベースバックアップと連続したWALアーカイブを組み合わせれば、条件を満たす範囲で特定時点へ復旧できます。
ただし、必要なWAL区間が一つでも欠ければ、その先へ連続して再生できません。アーカイブの保存成功だけでなく、実際に別環境へ復元し、目標時点まで到達できることを試します。レプリカへ誤削除が伝播することもあるため、独立した保持期間を持つバックアップが必要です。
SQLiteのWALモードは同名でも構成が違う
SQLiteでは、通常のrollback journalとは別にWALモードを選べます。
PRAGMA journal_mode=WAL;
SQLiteのWALでは変更を-walファイルへ追記し、checkpointで本体DBへ戻します。読み取りと書き込みを並行しやすくなりますが、同時writerは一つです。また共有メモリを使うため、通常は同じホスト上のプロセスという前提があります。
WALファイルはDBの永続状態の一部です。DBファイルだけを稼働中にコピーすると、コミット済み変更を欠いたり不整合になったりする可能性があります。バックアップはSQLiteが提供する方法と運用手順に従います。
長い読み取りトランザクションがあるとcheckpointを最後まで進められず、WALファイルが成長することがあります。SQLiteでも「WALモードにすれば保守不要」ではなく、接続の長さ、checkpoint、ファイルサイズを確認します。
クラッシュ時に何が起きるか
次の三つの停止時点を分けると、WALの役割を理解しやすくなります。
WALの永続化前
変更はメモリ上にあっても、耐久性を保証する地点へ達していません。通常、クライアントへコミット成功を返す前なら、そのトランザクションが失われても契約違反ではありません。
WALの永続化後、データページ書き出し前
コミット済みWALが残っているため、再起動時にREDOしてデータページを復元できます。これがwrite-aheadの中心的な場面です。
データページ書き出し中
ページの一部だけが更新された状態に備え、DBはページ情報とWALを使って整合した状態へ回復します。具体的な仕組みはDBとストレージ設定で異なります。
クラッシュリカバリが成功しても、ストレージ自体の消失、WALを含むファイル破損、誤操作による論理削除まで自動で戻るわけではありません。
運用変更の安全確認
WAL関連の設定変更は、書き込み性能、ディスク使用量、復旧時間、レプリカへ同時に影響します。
- 現在値と変更理由を記録する
- 本番に近い書き込み量でWAL生成量を測る
- checkpoint中のレイテンシを確認する
- クラッシュを模した再起動と復旧を試す
- アーカイブとレプリカが追随できるか確認する
- 元へ戻す条件を決める
ベンチマークで平均応答だけを見ると、checkpoint時のI/Oピークや長いtail latencyを見落とします。書き込みレイテンシのpercentileとディスクI/Oを同じ時間軸で確認します。
設定変更後は正常停止だけでなく、書き込み中のプロセス停止も検証します。復旧後にDBが起動すること、コミット成功と通知した取引が残ること、未コミット取引が見えないことを照合します。
WALを使う機能を区別する
| 機能 | WALの使い方 | 単独では保証しないこと |
|---|---|---|
| クラッシュ復旧 | 未反映の変更をREDOする | ストレージ全損からの復旧 |
| ストリーミングレプリケーション | 変更を別サーバーで再生する | 誤削除からの巻き戻し |
| 時点復旧 | ベースバックアップ後のWALを再生する | 必要なWALが欠けた区間 |
| 論理デコード | 変更を論理的なイベントとして読む | 任意DDLの完全な互換性 |
同じWALを利用していても目的と復旧条件が違います。監視と保持期間を機能ごとに確認します。
アプリケーションログとは別物
WALはDBエンジンがデータファイルを復旧するための内部記録です。利用者が「誰の注文を取り消したか」を調べる監査ログや、分散処理の業務イベントとは目的と形式が違います。
WALを直接読み、アプリの監査記録の代わりにすると、DBバージョン、記録形式、保持期間へ強く依存します。論理デコードやCDCで変更イベントを取り出す場合も、schema変更、同じイベントの再送、offset管理、個人情報の扱いを設計します。
逆に、アプリケーションログを残していても、DBページのクラッシュ復旧はできません。復旧用WAL、監査ログ、業務イベント、バックアップを、それぞれ必要な保持期間とアクセス権で管理します。
障害に備えて観測すること
- WALの生成速度と保持量
- checkpointの時間、頻度、I/Oの山
- レプリカやアーカイブ先の遅延
- ディスク残量
- 実際の再起動・復旧にかかる時間
WALが増え続ける時に、ファイルを手動削除してはいけません。長時間のレプリケーションスロット、失敗したアーカイブ、checkpointの停滞など、保持理由を製品の管理機能で確認します。
復旧演習の所要時間と手順は記録し、担当者が変わっても同じ判断で再現できる状態にします。記録は定期的に更新します。
よくある誤解
- WALがあればバックアップ不要：同じ障害や誤削除から守る独立バックアップが必要です。
- ログにはSQLがそのまま入る：記録形式は製品と設定で異なります。
- コミット後はデータページへ即反映済み：WALが先に永続化され、ページ反映は後の場合があります。
- WALを無効化すれば安全に高速化できる：耐障害性と復旧可能性を変えるため、要件なしに変更しません。
まとめ
WALの核心は、データページより先に復旧用ログを永続化する順序です。コミット、REDO、checkpointを分けて理解し、DB製品ごとの記録形式と同期設定を確認します。WALはバックアップの代わりではなく、復旧テストと監視まで含めて耐障害性を作ります。
