Hatena::Grouppostgresql

PostgreSQL 雑記 このページをアンテナに追加 RSSフィード

2010-08-29もっとレプリケーションのノウハウを このエントリーを含むブックマーク このエントリーのブックマークコメント

PostgreSQLのしくみ勉強会の「Hot Standby / Streaming Replication ハンズオンセミナー」に行ってきました。手順どおりにやれば動きますね、というところまでは手軽ですが、本当に運用に組み込もうと思うと、細かいところがまだまだ整理したいことは多いかなぁという印象です。

レプリケーション時に archive_mode を使うべき or 不要のパターンの整理
セミナーでは使わないパターンでしたが「もう昔のWALは消しちゃったよ」エラーでハマった方もいたもよう。それぞれの使い時を整理しておきたいところです。個人的には、レプリーケーションするのにバックアップをしないという運用パターンはありえないと思うので、archive_mode = on だけ覚えておけば良いのかなぁという気もしますが。
ノードの追加、停止、切り離し、再組み込みの手順の整理
セミナー後も、「クラスタ全体を停止しても大丈夫なんですか?」という質問が出てしまうくらい、いまいち何ができるのかがが伝え切れていないもよう。運用手順ごとに逆引き的に整理すると良いかもしれません。
異なるマスターに繋ぎ直す手順
FAQ、かつマニュアルどおりに回答すると非常にがっかりされる質問に、「フェイルオーバー後に最初とマスターに繋ぎ直す場合には、もう一度ベースバックアップが要るのですか?」があります。マニュアル的には「残念でした。もう一度バックアップしてね」なのですが、手元で試している限りは、適切なアーカイブログとバックアップ履歴ファイル (pg_xlog/*.history) にアクセスでき、かつ recovery.conf の recovery_target_timeline を新マスターに一致させれば問題なく復帰できるように見えます。どこまで許されるのか、整理したいところです。
スイッチオーバーならば大丈夫?
どちらもマスターを切り離してスレーブのどれかをマスターに昇格させることですが、故障などで予期せず起こる場合をフェイルオーバー、運用者の支持により行う場合をスイッチオーバーという気がします。上記の再組み込みにも関連しますが、もしマスターの切り替えに問題が生じるケースがある場合でも、スイッチオーバーであれば制限を飲めるケースもあるので (例えばいったん更新を停止するなど)、整理されていると嬉しいかも。

その他に、外部ツールとの組み合わせを整理したいですね。pgpool-II 3.0 は結構レプリケーション管理 & クエリ振り分けをがんばっているようですし、需要があるならスレーブのカスケードを自作しても良いですし。