PostgreSQLの「命綱」、WALアーカイビングを使いこなそう
やあ。今日はPostgreSQLの心臓部、というか「最後の砦」とも言えるWALアーカイビングについて話そうか。
現場でPostgreSQLを運用していると、たまに「バックアップは取ってるけど、リカバリのテストをしたことがない」なんていう少し怖い状況に遭遇することがある。君は大丈夫かな？
PostgreSQLにおいて、データベースを「特定の時点（Point-in-Time）」まで戻せるかどうかは、このWALアーカイビングが正しく動いているかどうかに全てがかかっていると言っても過言じゃない。今日は、理論的な話よりも「なぜこれが重要なのか」「現場でどう設定して管理すべきか」という、実践的な視点で掘り下げていこうと思う。
—
WALアーカイビングとは、結局何をしているのか
PostgreSQLは、データへの書き込みを直接データファイルに行う前に、まずは「WAL（Write Ahead Log）」というログファイルに書き出す。これはパフォーマンスと耐障害性のために必須の仕組みだよね。
WALアーカイビングは、このWALファイルが一杯になったり、一定時間が経過して「セグメント」として切り出されたタイミングで、そのファイルを別の安全な場所（S3やNFS、あるいは別のサーバー）へコピーする仕組みのことだ。
なぜこれが必要か？ 単純な話、「フルバックアップだけでは、直近のデータは守れないから」だよ。
例えば、深夜2時に取ったフルバックアップがあるとして、午後3時に誤って `DROP TABLE` を実行してしまったとする。WALアーカイビングがなければ、バックアップを取った深夜2時の状態までしか戻れない。でも、WALがアーカイブされていれば、午後2時59分59秒の状態までデータを復旧できる。これがPITR（Point-in-Time Recovery）の正体だ。
—
実践的な設定の勘所
まずは `postgresql.conf` の設定をサクッと確認しよう。
必須の設定
wal_level = replica # アーカイブには replica 以上が必要
archive_mode = on # アーカイブを有効化
archive_command = ‘test ! -f /mnt/server/archive/%f && cp %p /mnt/server/archive/%f’
ここで一番大事なのが `archive_command` だ。ここを適当に書くと、リカバリ時に痛い目を見る。
先輩からのアドバイス：
- `test ! -f` を忘れずに: ネットワークの一時的な瞬断などで同じファイルが転送されようとしたとき、コピーコマンドがエラーで止まるとアーカイバプロセス全体が死ぬ。`test` を挟んで「既にファイルがあったら何もしない（成功扱いにする）」という工夫が必要だ。
- パスは絶対に絶対パスで: 相対パスは事故の元。運用を開始する前に、必ず本番想定のディレクトリ構成で一度テストしてほしい。
—
実務で「詰む」前にやっておくべきこと
理論上はこれで完璧に見えるけど、現場で運用していると「ログが溜まりすぎてディスクが溢れる」という問題に必ずぶち当たる。
最近なら、`archive_command` を手で書くよりも、`pgBackRest` や `wal-g` といったツールを使うのが今のトレンドだ。これらは単純なコピーだけでなく、圧縮や並列転送、古いログの自動削除までやってくれる。
特に `wal-g` はS3との相性が抜群で、今のクラウドネイティブな環境ならこれ一択と言ってもいいくらい便利だ。手動でスクリプトを書いてメンテに追われるより、実績のあるツールに任せるのが「エンジニアの賢い手抜き」だよ。
—
復旧のシミュレーションを頭の中に
最後に一つだけ覚えて帰ってほしい。「アーカイビングしているだけでは、バックアップとは言えない」ということだ。
バックアップファイルとWALアーカイブがあるなら、一度その環境を別のサーバーに展開して、`recovery.signal` を置いて起動できるか試してみてほしい。もし本番で障害が起きたとき、慌ててコマンドを調べているようでは遅すぎる。
「いざという時に、このWALを使って何分で復旧できるか？」
その感覚を一度でも体感しておけば、君の運用に対する自信は段違いになるはずだ。
PostgreSQLは堅牢なデータベースだけど、その堅牢さを引き出すのはあくまで運用する側の工夫次第。何か詰まったら、いつでも聞いてくれ。応援してるよ。
コメント