« 【メモ】Postgre9.1系→9.3系の変更点 | トップページ | 肩こり対策グッズ »

2014.03.09

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だ!(笑)

|

« 【メモ】Postgre9.1系→9.3系の変更点 | トップページ | 肩こり対策グッズ »

コメント

財布、腕時計物、バッグ 販売
こんにちは、お客様。
突然の投稿大変失礼いたします。
弊社は、主にブランド品の輸入を取り扱っております。
誠実信用の販売 期待はあなたと楽しい付き合いを持っています!

主要な特徴:
1.商品に対して厳格な検査をしています.
2.入金の後で、在庫(品)のない商品を発送して、私の店は銭做を返します.
3.もし商品は税関に没収するならば、絶対的な再度は無料で商品を発送します.
4.もし到着する商品に対して満足しませんならば、私の店のとても良いのはして品物の交換に帰って、あるいはお金を返します.

その他

EMS(国際速達郵便)運輸 全国一律送料無料

業者の方の買い付けも歓迎です
スーパーコピー 財布 ダミエ コピー https://www.japan456.com/product/detail-7388.html

投稿: スーパーコピー 財布 ダミエ コピー | 2020.12.12 04:21

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: pg_xlogのパンク:

« 【メモ】Postgre9.1系→9.3系の変更点 | トップページ | 肩こり対策グッズ »