PostgreSQLのWALアーカイビング：堅牢なデータ保護の「心臓部」を解剖する
PostgreSQLを運用するエンジニアにとって、WAL（Write Ahead Log）は単なる「ログ」ではありません。それはデータベースの生存と死、そして過去への帰還を司る生命線です。
特に「WALアーカイビング」は、バックアップ戦略の要でありながら、トラブルシューティングの現場では往々にしてブラックボックス化しがちです。今回は、このWALアーカイビングの深層を、アーキテクチャとトラブルシューティングの両面から紐解いていきましょう。
—
WALアーカイビングの「内側」で起きていること
WALアーカイビングは、`archive_command` という単純なインターフェースの裏側で、非常にシビアな同期制御を行っています。
1. WALセグメントのクローズ: PostgreSQLは、`wal_segment_size`（デフォルト16MB）に達するか、あるいは`archive_timeout`が経過すると、現在書き込み中のWALセグメントを「完了状態」としてマークします。
2. Archiverプロセスの介入: ここでメインのバックグラウンドプロセスとは独立した「Archiverプロセス」が起動します。これが`archive_command`を実行し、OSレベルのシェルを介してWALファイルを外部ストレージへ送出します。
3. 成功の確認: PostgreSQLは、コマンドの終了ステータス（exit code 0）を確認するまで、そのWALセグメントを削除しません。ここが重要です。コマンドが成功しなければ、WALは蓄積され続け、ディスクを圧迫するという物理的な脅威に直面します。
—
現場で直面する「落とし穴」とチューニングの勘所
熟練のエンジニアであれば、一度は「なぜかアーカイビングが詰まる」という事象に遭遇したことがあるはずです。その原因の多くは、アーキテクチャの制約に起因します。
1. archive_commandの同期的な制約
`archive_command`はPostgreSQLの外側で実行されるシェルスクリプトです。もし、転送先（S3やNFSなど）のネットワーク遅延やI/O負荷によってコマンドが停滞すると、Archiverプロセスはそれに引きずられます。
- トラブル対応: `archive_command`の中身は極力シンプルにすべきです。圧縮や転送は非同期キューイングを利用する方が、PostgreSQL本体への影響を最小限に抑えられます。
2. pg_wal ディレクトリの肥大化と監視
アーカイビングが失敗し続けると、`pg_wal`配下にファイルが積み上がり、最悪の場合OSのパーティションを食いつぶしてデータベースが停止します。
- 実戦的な監視: `pg_stat_archiver`ビューを常に監視対象に入れてください。特に`failed_count`がカウントアップされている場合、それは「バックアップが死んでいる」ことを意味します。このメトリクスに対するアラートは、死活監視と同レベルの優先度が必要です。
3. archive_timeoutのジレンマ
`archive_timeout`を短くすればPITR（ポイントインタイムリカバリ）の精度は上がりますが、Archiverプロセスの頻度が増え、CPU/I/Oオーバーヘッドが無視できなくなります。
- チューニングの指標: 私は通常、ビジネス側が許容できる「データの損失許容時間（RPO）」を起点に、10分〜1時間に設定することが多いです。闇雲に短くするのではなく、リカバリ時の「WAL再生にかかるコスト」と「RPO」のバランスを天秤にかけて判断してください。
—
次世代のアーカイビング：pgBackRestの推奨
現代のPostgreSQL運用において、シェルスクリプトによる`archive_command`の自作は、もはや「車輪の再発明」どころか、リスクでしかありません。
現在、私が現場で最も信頼を置いているのは [pgBackRest](https://pgbackrest.org/) です。
- 並列転送: ネットワーク帯域を使い切るマルチスレッド転送が標準。
- デルタ復旧: 必要な部分のみを転送・復旧する賢さ。
- 堅牢な検証: WALのチェックサム検証や、リポジトリの整合性管理が極めて強力。
`archive_command`に`pgbackrest archive-push`を指定するだけで、それまでの複雑なシェル管理から解放されます。データベースのアーキテクチャを深く理解した上で、あえて「信頼できる成熟したツール」に委ねる。これもまた、プロフェッショナルな判断だと私は考えています。
—
最後に
WALアーカイビングは、PostgreSQLの「誠実さ」を象徴する機能です。どんなに派手なクエリチューニングも、データが失われてしまえば無意味です。
「アーカイビングが動いていることは、当たり前ではない」。そう自戒しながら、ぜひ皆様のシステムの`pg_stat_archiver`を一度覗いてみてください。そこには、あなたのデータベースの安全を守るための、地味だが確実な営みが刻まれているはずです。
では、また次回の深い技術談義でお会いしましょう。
コメント