PostgreSQLの心臓部を覗く：クラッシュリカバリとREDOログの「静かなる再構築」
データベースエンジニアとして長く現場に立っていると、ふと「もし今、このサーバーの電源が物理的に落ちたら？」という光景を想像することがあります。PostgreSQLにとって、その瞬間は「死」ではなく、次なる「再生（リカバリ）」への序章に過ぎません。
今回は、PostgreSQLの堅牢性を支える根幹、WAL（Write Ahead Log）と、それがクラッシュ後の世界をどのように再構築するのか、そのREDOプロセスの深淵を覗いてみましょう。
なぜ「フルページライト（FPI）」が不可欠なのか
リカバリの話をする前に、避けて通れないのが「ページ書き込みの不整合問題」です。OSのページサイズ（通常4KB）とPostgreSQLのページサイズ（通常8KB）の不一致により、OSの書き込み途中でクラッシュが発生すると、データファイル上のページが「前半は新しく、後半は古い」という、いわゆる断片化された状態になります。
PostgreSQLはこれを防ぐために、チェックポイント後の最初の書き込み時に、ページ全体をWALに書き出す「フルページライト」を行います。この仕組みがあるからこそ、REDOプロセスは「過去の汚れたページ」を「正しい状態」へと上書きする、確固たる足場を得られるのです。
REDOプロセスのアルゴリズム：機械的な適用ではない
クラッシュ後のデータベースが起動する際、PostgreSQLはまず「Redo Start Point」を特定します。これは、最後に正常に完了したチェックポイントの場所から始まります。
REDO処理の本質は、以下のステップで淡々と、しかし極めて厳密に進行します。
1. WALの再読： チェックポイントのログ位置から、WALの末尾までをシリアルに読み進めます。
2. LSN（Log Sequence Number）による照合： 各データページには、そのページが最後に更新された際のLSNが刻まれています。REDOプロセスは、ログレコードのLSNと、データファイル側のページLSNを比較します。「ログのLSNがページLSNより大きい場合のみ、更新を適用する」というこの単純なルールが、冪等性（Idempotency）を担保し、リカバリの安全性を支えています。
3. 無駄を省く最適化： すでにページが最新の状態であれば、REDOは何もせずスキップします。これが「リカバリが再開可能である」というPostgreSQLの強みの源泉です。
トラブルシューティングの視点：リカバリが「重い」と感じるとき
現場でよくあるのが、「クラッシュリカバリに時間がかかりすぎてサービスインできない」という悲鳴です。この原因の多くは、以下のポイントに集約されます。
- チェックポイント間隔の過度な短縮： チェックポイントを頻繁に行うと、ディスクI/Oへの負荷は分散されますが、一方でWALの生成量や物理的なデータ書き込みのオーバーヘッドが増大します。バランスを欠いた設定は、リカバリ時に「再適用すべきログ」の山を築くことになります。
- ストレージのランダムI/Oボトルネック： REDOプロセスはシーケンシャルにログを読みますが、更新対象のデータページをメモリにロードする際にはランダムアクセスが発生します。リカバリ時間が長い場合、ストレージのIOPS限界に達している可能性が高いです。
- OSキャッシュの汚染： 大量更新後のクラッシュでは、OSのページキャッシュがフラッシュされる前にリカバリが始まります。この際、WALの読み込みとデータファイルの読み込みが競合し、リカバリ性能を著しく低下させることがあります。
最後に：PostgreSQLを信じるということ
REDOリカバリは、非常に堅牢に設計されています。しかし、それは「適切な設定」という基盤があってこその話です。
私はよく、「リカバリ時間は最大の障害対策指標である」と言います。WALの量、チェックポイントの設計、そしてハードウェアのI/O性能。これらが組み合わさった結果が、あなたのPostgreSQLの「復活力」となります。
もし今、皆さんの環境でリカバリ速度に不安があるなら、まずは `checkpoint_completion_target` の値と、`max_wal_size` を見直してみてください。そして何より、定期的に「本番と同等の負荷をかけた状態でのクラッシュテスト」を実施することをお勧めします。
理論を知ることは重要ですが、実際にログが適用され、データベースが蘇生するその瞬間を自身の目で確認すること。それこそが、エンジニアとしての確かな自信に繋がるはずです。
それでは、また次回の深掘りでお会いしましょう。ログの向こう側に、安定した稼働があることを願って。
コメント