pg_xlogのパンク
アラートメールが飛んできて、急激にある領域がくいつぶされている、ということだった。
何が起きているのかとばたばたしているうちにサービスが停止し、DBへの接続ができなくなってしまった。
さらに泡を食っている間に、サービスはいつの間にか回復しており、システムは問題なく稼動を継続してしまった。
こういう経験はおありだろうか？
というかpg_xlogが何をしているのかを私が理解していなかったので、まずはそこからの調査となった。
今回のサーバではpg_dataとpg_xlogは物理的に異なるディスクにマウントされていた。
結論からいえば、pg_xlogディレクトリにはWALログを記録する領域であった。
このWAL(write ahead log)：先行書き込みログと呼ばれるものはいわゆるジャーナル、Informixでいえば論理ログと同等と考えればいいだろうか。
PITR(Point In Time Recovery)すなわちテープ等のバックアップだけでなく、トランザクションをすべて記録しておき、クラッシュの直前までDBの状態を戻せるための鍵がこのWALということになる。
大量のトランザクション処理があるならば当然発行されたSQLは大量になる。
いくらなんでもディスクも無限ではないから、このWALもいずれかのタイミングで廃棄しなければなるまい。
PostgreSQLの場合特徴的なのは、このWALのアーカイブ方法は管理者に任せる、ということになっておりアーカイブするためのコマンドなどは準備されていない。
で、この領域がパンクした、ということなのだが、ウチの環境ではgzip処理をしていたらしい。
しかし作業パスがpg_xlogであったために山盛りのWALがある状態でgzファイルを作成し続けて、クォート不足に陥ってしまったのが真相のようだった。
アーカイビングについては別の作業パスで行うようにした方が良いのかもしれない。
あるいはチェックポイントの設定が大きすぎて、「不要な」WALになるサイクルが長すぎたのかもしれない。
このあたりはもう少しアプリ特性を見ながら対策を考えることとしよう。
なお、PITRは運用しているシステムが突然落ちた場合には非常に有効なリカバリーであるが、たとえば夜間バッチ処理の前後でバッチの影響を全く受けてない／完全に受け終わったデータのスナップショットを必要とする場合はpg_dumpを使う方が良いので、このあたりはどのようなバックアップ・リカバリー計画を立てるのか次第で、上手に使い分けたいところだ。
現実的にウチの環境ではインフラチームがPITRできるようにpg_start_backup()してくれてはいるが、その実行タイミングについてははしなくも意識があってないことがわかった。
DevOpsだ！（笑）
| 固定リンク
コメント