データベースの「不死身」を支える心臓部：WALリカバリの深淵へ
PostgreSQLを運用していて、最も胃が痛くなる瞬間はいつだろうか？ 突然の電源断、OSのカーネルパニック、あるいはストレージコントローラーの沈黙。管理画面が真っ暗になり、静寂が訪れるあの数秒間だ。
しかし、再起動コマンドを叩いた直後、PostgreSQLはまるで何事もなかったかのようにログを吐き出し、整合性を復旧させる。この「不死身」とも言える挙動の裏には、WAL（Write Ahead Logging）という非常に洗練された、しかし過酷な運命を背負ったメカニズムが存在している。
今日は、そのWALリカバリのプロセスについて、単なる「復旧手順」を超えて、アーキテクチャの核心部分を少し深掘りしてみたいと思う。
—
REDOの真実：単なる「再実行」ではない
多くのエンジニアは、リカバリを「止まった時点からログを順番に再適用すること」と理解しているだろう。だが、PostgreSQLのリカバリはもっと賢い。
PostgreSQLのリカバリプロセスは、LSN (Log Sequence Number) を軸に動いている。すべてのデータページには、そのページが最後に更新された時点のLSNが刻まれている。一方で、WALには更新の履歴が時系列で並んでいる。
リカバリの際、PostgreSQLは以下のロジックを極めて高速に実行する。
1. チェックポイントの特定: Control Fileから、最後のチェックポイント位置を特定する。
2. REDO開始地点の決定: そのチェックポイントからログを読み進める。
3. ページレベルの比較: WALのレコードを読み込むたびに、対象ページがすでにその変更を反映しているかを確認する。ここでLSNが効いてくる。WALのLSNがページ上のLSNより大きければ、初めて適用を行う。
この「すでに適用済みであればスキップする」という設計のおかげで、リカバリの途中で再びクラッシュしても、最初から安全にやり直すことができる。この冪等性（Idempotency）こそが、PostgreSQLの堅牢性の根幹だ。
—
パフォーマンスのボトルネック：なぜリカバリは時間がかかるのか
大規模なインフラを運用していると、「DB再起動時のリカバリ時間が長すぎる」という問題に直面することがある。ここでのボトルネックは、多くの場合CPUではなく「I/Oの非効率性」にある。
- ランダムI/Oの嵐: WALには更新の差分が記録されているが、それらが適用されるデータページはディスク上のランダムな位置にある。ディスクI/Oがボトルネックになると、リカバリの進捗は目に見えて鈍化する。
- Double Writeの不在: PostgreSQLは（MySQLのInnoDBとは異なり）ページ単位の完全書き込みではなく、WALをベースにしたリカバリを行う。そのため、リカバリ中は膨大な読み書きが発生する。これを緩和するには、OSレベルのファイルシステムキャッシュを有効活用するか、そもそも`checkpoint_completion_target`を適切に調整してチェックポイントの間隔を広げることが重要になる。
もし、リカバリ時間を劇的に短縮したいのであれば、物理的なディスク性能（特にIOPS）を上げるのはもちろんのこと、`max_wal_size`の設定を見直すべきだ。ここを極端に小さくするとチェックポイントが頻発し、リカバリすべき範囲は狭まるが、平常時の書き込み負荷が跳ね上がる。このトレードオフをどう調整するか。それがシニアエンジニアの腕の見せ所だ。
—
トラブルシューティングの勘所：ログを読み解く
リカバリがスタックしている時、あるいは無限ループのように再起動を繰り返す時、私が見るのは`pg_wal`の中身だ。
pg_waldump -p /var/lib/postgresql/data/pg_wal [WALファイル名]
このコマンドは、リカバリの最前線を知るための「聴診器」だ。どのレコードでリカバリが止まっているか、あるいはどのページでエラーが出ているか。それを追うだけで、物理破損なのか、あるいは論理的な整合性エラーなのか、大抵の当たりはつく。
特に厄介なのが、ストレージのビット化けによるWALレコードの破損だ。リカバリプロセスは、壊れたWALに遭遇するとそこで停止する。この時、無理に`pg_resetwal`に頼るのは最後の手段だ。それはデータベースの「健忘症」を引き起こす行為であり、データの不整合を確定させてしまう。
—
最後に：アーキテクチャを「信頼」するということ
PostgreSQLのリカバリプロセスは、20年以上の歳月をかけて洗練されてきた。トランザクションのACID特性を守るために、どれほどのエンジニアがこの「REDOの儀式」を磨き上げてきたかを想像すると、敬意すら覚える。
障害時に「なぜ止まったか」を追うのは大切だ。しかし、「なぜ再開できたか」というアーキテクチャの美しさを理解しておくことも、同じくらいエンジニアには必要だと思う。
データベースは単なるデータの箱ではない。自らの状態を一貫させるための「意志」を持ったプロセスだ。その意志を理解し、適切にケアしてやること。それが、高負荷環境でPostgreSQLを走らせる我々の仕事ではないだろうか。
また、次回の記事では、このリカバリプロセスを応用した「ポイントインタイムリカバリ（PITR）」の裏側と、レプリケーションとの密接な関係について語ってみたいと思う。
それでは、良いDBライフを。
コメント