【実務・中級編】 WALリカバリプロセス – PostgreSQL

「なぜPostgreSQLは突然の停電でも壊れないのか？」— WALリカバリの裏側を紐解く

エンジニアの皆さん、こんにちは。

本番環境でPostgreSQLを運用していて、ヒヤッとした経験はありませんか？例えば、物理サーバーの電源が予期せず落ちてしまったり、OSがカーネルパニックを起こして強制再起動したり……。

「あ、これデータ飛んだかな？」と冷や汗をかきながらログを眺め、PostgreSQLが猛烈な勢いでログを読み込んでいるのを見て安堵する。あのプロセスこそが、今回掘り下げる「WALリカバリ」です。

今日は、教科書的な仕組みの話に少しだけ現場のスパイスを加えて、この「データベースの命綱」が裏でどう動いているのか、一緒に見ていきましょう。

—

1. 「書き込み」の常識を疑う：WALはなぜ必要なのか？

まず、大前提を整理しましょう。ディスクへの書き込み（I/O）は、コンピューターの世界で最も「重くて遅い」処理の一つです。

PostgreSQLは、テーブルやインデックスのデータを毎回ディスクに物理書き込みするなんて非効率なことはしません。まずはメモリ（Shared Buffers）で更新を完結させ、タイミングを見計らってディスクへ反映（チェックポイント）します。

でも、もしその途中で電源が落ちたら？メモリ上のデータは消え、ディスク上のデータは中途半端な状態（不整合）になりますよね。

そこで登場するのが WAL（Write-Ahead Logging） です。
「データを変更する前に、まず変更内容をログとして順番に書く」。これがPostgreSQLの鉄則です。このログさえあれば、最悪の事態でも「過去のどこまでが安全だったか」を特定し、そこから先を再現できるわけです。

2. クラッシュリカバリの「3ステップ」

PostgreSQLが再起動する際、内部では何が起きているのか。ざっくり言うと、以下の3段階を踏んでいます。

1. REDO開始地点の特定: チェックポイントのレコードを探し、「ここまでは安全にディスクに反映されている」という地点を特定します。
2. REDO（再実行）: その地点から、最新のWALログを一つずつ読み込みます。「このページをこう書き換える」という操作を、順序通りにメモリ上で忠実に再現します。
3. 一貫性の確保: 全ての再適用が終わると、メモリ上の状態とディスク上のデータが同期され、データベースがオンラインになります。

現場で「起動がやけに遅いな？」と感じる時は、大抵このステップ2のWAL適用が長引いている時です。ログが溜まっていればいるほど、リカバリには時間がかかる、というわけですね。

3. 実践：リカバリを意識した運用ポイント

この仕組みを知っておくと、運用設計も少し変わってきます。

Max_wal_size のバランス

最近のバージョンでは自動チェックポイントが賢いですが、依然として `max_wal_size` は重要です。ここを大きくしすぎると、リカバリ時間が指数関数的に増大します。「書き込み性能」と「リカバリ時間」のトレードオフを意識しましょう。

実際にWALを確認してみる

もし皆さんが「今どれくらいのWALが溜まっているんだろう？」と気になったら、以下のクエリを叩いてみてください。

— 現在のWALの書き込み位置を確認する
SELECT pg_current_wal_lsn();

— 最後にチェックポイントが実行されてからの経過量などを確認
SELECT FROM pg_stat_bgwriter;

特に `pg_stat_bgwriter` の `checkpoints_timed` と `checkpoints_req` の比率は見ておいて損はありません。`checkpoints_req` が異常に高い場合は、書き込み負荷に対してチェックポイントの頻度が最適化されていない証拠です。

4. 先輩からのアドバイス：ログは「未来」を知っている

最後に一つだけ。WALリカバリは、単なる「復旧のための保険」ではありません。「Point-in-Time Recovery (PITR)」という強力な武器の土台でもあります。

「間違えて `DROP TABLE` しちゃった！」という絶望的な状況でも、WALをアーカイブしておけば、特定の一瞬まで時間を巻き戻すことができます。

バックアップを定期的に取る（pg_basebackupなど）
WALを別の安全なストレージに保存（archive_mode = on）

この2つを徹底するだけで、データベースエンジニアとしての信頼度は段違いに上がります。「最悪の事態」を想定してリカバリの手順を一度でもシミュレーションしておくと、本番でトラブルが起きた時の心の余裕が全く違いますよ。

—

データベースの仕組みは、一見とっつきにくいかもしれません。でも、一つ一つのプロセスが「データの整合性を守るための執念」の塊だと考えると、なんだか愛着が湧いてきませんか？

また分からないことがあれば、いつでも聞いてください。現場で一緒に手を動かしていきましょう！