やあ。PostgreSQLの運用、順調かな？
「バックアップは命綱」なんて言葉は聞き飽きたかもしれないけれど、いざという時にその命綱が切れていたら……想像するだけで冷や汗が出るよね。
今日は、その命綱の根幹を支える`archive_command`について、教科書にはあまり書いていない「現場のリアル」を話そうと思う。
—
なぜ `archive_command` が必要なのか？
PostgreSQLは、データの整合性を守るために「WAL (Write Ahead Log)」というログを書き出しているよね。でも、サーバーがクラッシュした時のリカバリ（Point-in-Time Recovery: PITR）を考えた時、WALだけでは足りない。なぜなら、WALは上書きされて消えてしまうからだ。
そこで登場するのが `archive_command` 。こいつは、「WALセグメントが一杯になったら、指定した場所に退避させて、消える前に保存しておく」という、いわばバックアップの門番だ。
基本的な設定と書き方
`postgresql.conf` に設定するこのコマンド、実はただのシェルコマンドなんだ。
archive_mode = on
archive_command = ‘test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f’
ここで使われている `%p` と `%f` は、PostgreSQLが自動的に展開してくれる変数だよ。
- `%p`: アーカイブ対象のWALファイルのフルパス
- `%f`: WALファイル名
なぜ `test ! -f` を入れるのか？
よくある質問なんだけど、これは「二重コピー防止」だね。万が一、何らかの理由でプロセスが再送された時に、既にファイルがあるなら上書きせずにエラーを返すのが安全策なんだ。
—
現場で必ず直面する「失敗」との付き合い方
ここからが本題だ。教科書では「設定して終わり」だけど、実務では「失敗した時」の挙動こそが重要なんだよ。
1. コマンドが失敗したらどうなるか？
`archive_command` が終了ステータス0以外（つまり失敗）を返すと、PostgreSQLはしつこく再試行を繰り返す。これは正しい挙動だ。データが失われるよりは、再試行してくれたほうがいいからね。
2. 「溜まり続けるWAL」という恐怖
気をつけないといけないのは、「アーカイブ先に転送できないと、WALが無限に増え続ける」ということだ。ディスク容量が食いつぶされて、最悪の場合、データベースが停止する。
これを防ぐために、現場ではこんな工夫をしている。
- 監視をサボらない:
`pg_stat_archiver` ビューを定期的にチェックするスクリプトを仕込んでおこう。
SELECT last_failed_wal, last_failed_time FROM pg_stat_archiver;
もしここが動いていたら、即座にアラートを飛ばす設定にすること。
- タイムアウトを設定する:
ネットワーク越しにアーカイブする場合、レスポンスがなくてプロセスがぶら下がる（ハングする）ことがある。コマンドには必ずタイムアウトを入れよう。
—
先輩からの実践的なアドバイス
最近のトレンドとしては、単純な `cp` コマンドではなく、`pgBackRest` や `Barman` といったツールを使うのが主流だ。なぜなら、単なるコピーだけでなく、圧縮や並列転送、完全性チェックまで面倒を見てくれるからね。
もし君が今、ゼロから環境を作っているなら、まずは `cp` で仕組みを理解して、その後にこういったツールへの移行を検討することをお勧めするよ。
最後にひとつだけ
設定を変えたら、必ず `SELECT pg_switch_wal();` を実行して、即座にWALを切り替えてテストするのを忘れないで。
「設定したから大丈夫だろう」という慢心が、一番のバグを生むんだ。
バックアップは「保険」じゃない。「運用の一部」だ。
この意識を持つだけで、君は他のエンジニアより一歩抜きん出た存在になれるはずだよ。
また何か詰まったら、いつでも聞きに来てくれ。健闘を祈るよ！
コメント