第11回PostgreSQLアンカンファレンス@東京で発表した資料です。設計や導入、サポートを行う中で直面した失敗談を紹介します。何かの参考にしてください。

1. POSTGRESQL失敗談 目黒聖

2. 自己紹介
名前：目黒聖
Twitter：まぐろ（@tameguro）
某都内中小SIer勤務
PostgreSQLを初めて触ったのは8.4
現在はPostgreSQLの設計・導入がメイン
自分が実際に設計や導入、サポートを行う中で直面した失敗談を紹介します
何かの参考にしてください
そして俺はこのときにどうすればよかったのか教えて下さい

3. 目次
ディスク容量は考えて使え
ログローテーションは難しい
レプリケーションスロットを使え
WALもバックアップしてください

4. ディスク容量は考えて使え
とある案件にて、同じサーバにPostgreSQLのインスタンスを5つ起動した
いという要望があった
本当にそれでいいのか確認したが、そもそも顧客内でも話が二転三転してい
てとりあえず環境を作ってほしいという依頼
担当Aさんに指定されたパーティションに5つデータベースクラスタを作成
し、それぞれポート番号が重複しないようにし、起動するまで完了した

5. ディスク容量は考えて使え
しばらくしたら、データベースクラスタがあるパーティションの容量がギリ
ギリになっているから場所を変えてほしいという依頼が来た
担当Bさん「他にたくさん容量を確保しているパーティションがあるのにな
ぜこんな狭いところに作ったんですか？」
 Aさんに言われたのと、Bさんがいうパーティションは本番稼働データベースクラスタがあ
るパーティションなので避けていた
担当Bさん「とにかく移動してください」

6. ディスク容量は考えて使え
データベースを停止してもいいので、データベースクラスタだけなら移動し
て起動しなおせばいいのだが、今回はテーブル空間を別ディレクトリに作成
していた
考えた方法
 新しくinitdbを作成し、pg_dumpでデータを入れ込む
 もしデータが欠損したら？
 テーブル空間も移動すればよくね？
 やってみよう！

7. ディスク容量は考えて使え
テーブル空間のディレクトリのパスをデータベース内で持っていたら、単純
に移動するだけでは最悪起動しない自体に陥るのでは？
pg_tablespaceにはディレクトリパスは保存していない
名前 型 参照先 説明
oid oid
行識別子（隠し属性です。明示的に選択しなければな
りません）
spcname name テーブル空間名
spcowner oid pg_authid.oid
テーブル空間の所有者。たいていはテーブル空間を作
成したユーザ
spcacl aclitem[] アクセス権限。 GRANTとREVOKEを参照してください。
spcoptions text[]
「keyword=value」文字列のようなテーブル空間レベ
ルのオプション。

8. ディスク容量は考えて使え
データベースクラスタのpg_tblspcディレクトリ内にoidでシンボリックリンクが
張ってあるだけ
 ならシンボリックリンク張り替えればいけるんじゃね？
いけました
 インスタンス停止
 データベースクラスタ移動
 テーブルスペース移動
 シンボリックリンク張り替え
 インスタンス起動
そもそもこのやり方はただしいのか？
ディスク容量はよく考えてデータベースファイルを格納する先を決めましょう

9. ログローテーションは難しい
ログ監視ソフトでPostgreSQLのログを監視したいので、できればログファ
イル名は変えないで欲しい
 PostgreSQLの機能でログローテーションするとどうしてもファイル名が一定にはならない
 log_rotation_age
 log_rotation_size
 log_filename
Linuxなんだからlogrotateを使えばいいのでは？
悲劇の始まりでした

10. ログローテーションは難しい
導入後しばらくたって、「ログがローテーションされていないようで、ログ
が肥大化している」との連絡が
見てみると、一応ログはローテーションされているが、変名して過去のログ
になったはずのログファイルに延々とログが出力され続けている
 どうやら名前だけ変えてもPostgreSQLはそのファイルに書き続けるらしい
 設定次第ではいけるらしいが、ログの欠落が起きる可能性が小さいとはいえありうる
結局log_rotation_ageとlog_rotation_sizeで対応し、ログの名前はごめん
なさいしました
早く対応してくれ！という依頼だったのでその日のうちに対応したので調べ
られる時間が限られたのですが、どうにかしてファイル名変えずにローテー
ションする方法ありますか？

11. レプリケーションスロットを使
え
レプリケーションする際に、レプリケーションスロットを使うように構成し、
稼働していた
ある日、WALがずっとたまってるんだけどこれは正常？という連絡が
当然正常ではないので事情聴取
 レプリケーションは正常にできているようだ
 WALがたまってディスク容量の限界に来ると、インスタンスが停止することを説明
 「消してもいいですか？」「絶対ダメです！」

12. レプリケーションスロットを使
え
予想通り、レプリケーションスロットがレプリケーションするWALを管理し
ているため、「まだこのWALはレプリケーションされてない」と判断して溜
め込んでいた
セカンダリのrecovery.conf見てください。primary_slot_nameは指定して
ありますか
 「ないです」「は？」
原因はレプリケーションスロットを無視してストリーミングレプリケーショ
ンをしていたこと
 レプリケーションスロットを削除
 WALファイルが減少したらセカンダリを停止
 プライマリでレプリケーションスロットを作成
 セカンダリのrecovery.confにprimary_slot_nameを指定して起動

13. レプリケーションスロットを使
え
何かのテストでプライマリ／セカンダリを入れ替えたときに、
recovery.confの書き方を間違えたらしい
レプリケーションスロットを使用するときに、WALがたまり続ける現象は有
名な話なので、もちろん手順書にレプリケーションスロットの使い方を記載
していた
俺「こういうふうに使ってください」
敵「あ、手順書通りなんですね」
俺「は？」

14. WALもバックアップしろよ！
自分が関わっていない案件で、PostgreSQLのバックアップの運用を設計し
ていた
担当「まぐろさん、バックアップするファイルはこれでいいですか？」
俺「とりあえず、データベースクラスタもWALも、データベースに関わる
ファイルは全部バックアップしてください」
ある日、バックアップからリストアする手順の確認をする日がやってきた
俺「WALは？」
担当「アーカイブ取ってるからいいかなと思ってWALはバックアップしてな
いです」
俺「は？」

15. WALもバックアップしろよ！
WALは自分の現場ではなぜか軽視されがちですが、基本的にないと動きませ
ん
 よく削除されそうになる
 実際に削除される
 バックアップ対象外にされる
ないものは仕方ないのでどうにかこうにかリストアしてみる
 pg_resetwal -f $PGDATA
 こんなん初めて使ったわ
詳細は省くがWALは起動に必要なファイルなので消さないでね！！