Yoshiharu Mori
y-mor****@sraos*****
2011年 11月 16日 (水) 18:53:28 JST
松尾さん 盛です。 新しいRAの動作確認を行いました。 ２台でも3台でも問題なく動いています。 同期レプリケーション3台構成を試しましたが、一点だけ質問です。 スレーブ2台が同じxlogの値を保持している場合、 SYNCとPOTENTIALはどういった基準(どちらがSYNCになる？） で決定されますか？ #早いもの勝ちですか？ また、一点だけドキュメントのミスがありました。 CRMサンプルにおけるmaster_ip設定は、recovery.conf内の primary_conninfoに記載されるPrimaryサーバのIPアドレスなので、 vip-repに指定したIPアドレス192.168.3.201を設定するのが 正しいですよね？ 以上です。 > 盛さん > RAに興味持って頂いている皆様 > > 松尾です。 > > PostgreSQLレプリケーション対応RAの仕様を少し変更しましたので、 > お知らせします。一端これで大きな変更は止めたいと思います。 > > https://github.com/t-matsuo/resource-agents/blob/pgsql91/heartbeat/pgsql > > > 主な変更点は以下の３点です。 > > * 一部パラメータを削除し、パラメータのデフォルト値(ファイル名)を変更しました。 > > パラメータが多すぎるので、tmpdir 配下に作るファイルのパスを個別に > 変更するパラメータを削除しました。ファイル名は以下のように変更になり、固定なります。 > > - ${tmpdir}/PGSQL.5432.rep_mode.conf -> ${tmpdir}/rep_mode.conf > - ${tmpdir}/PGSQL.5432.force_start_file -> ${tmpdir}/PGSQL.lock > - ${tmpdir}PGSQL.5432.xlog_note -> ${tmpdir}/xlog_note > > * master-baseline という属性値が表示されるようになりました。 > > 下記のstart時の整合性をチェックするため、Master で表示される属性値です。 > 内容はpromote直前のTImeline ID とxlogの位置です。 > 表示形式は ID:CHCKPOINT位置(16進数16桁) > (例) 10:000000200000FFFF > > > * start (Slave起動) 時に、データの整合性を確認する処理を入れました。 > > 起動時に、自分のLatest checkpoint location および Timeline IDを > 上記のmaster-baselineと比較して判断します。 > TImeline ID がmaster-baselineのIDより大きければリストアしたデータとみなし、 > start成功します。よって盛さんが懸念されていた、リストア後のフラグ削除のような > 処理を避けることができます。 > > ※ 最新のPostgreSQL 9.1.1 のバグにより、Master切替時にこの整合性チェックに > ひっかかってmonitor NGが発生します。PG関係者には報告済みで、 > 9.1.2 では修正されるのではないかという噂は聞きましたが詳細はわかりません・・・ > > > 以上です。 > > > 2011年10月17日19:22 Takatoshi MATSUO <matsu****@gmail*****>: > > 盛さん > > 松尾です。 > > > > 返信遅くなってすみません。 > > > > > > 2011年10月12日14:19 Yoshiharu Mori <y-mor****@sraos*****>: > >> 松尾さん > >> > >> 盛です。 > >> > >>> しかし、個人的な感覚ではやはり rsync コマンドなのでデータ全体をバックアップする > >>> 人も結構いらっしゃる気がしますので(私もやってます・・)、やはり pg_xlog が空かどうかで判断するのは > >>> あまり嬉しくない実装かなと思います。 > >> > >> たしかに、xlogでの確認はちょっとどうかなーという感じがしますね。 > >> force_start_fileを逆に利用するのはいかがでしょうか？ > >> > >> -初回はforce_start_fileが存在しないので必ず立ち上げを試みる > >> -起動後にforce_start_fileを作成しforce_start_fileを残しておく > >> -force_start_fileがある限り、pg_controldataの値が正常でないと起動しない > >> -force_start_fileを削除すると常に立ち上げを試みる > >> > >> ファイル名と逆の関係で(説明も)紛らわしいですが。。 > > > > ファイル名は変えるとして、上記案の方が確かによさそうですね。 > > 上記のように起動時にフラグを作るなら、正常シャットダウン時(fast)に、削除してあげることで、 > > データベースの状態を見る必要もなくなりそうです。 > > > > 具体的には、 > > > > 正常時 > > 起動完了後フラグ作成 > > fast shutdown成功時にフラグ削除 > > 次回起動時フラグがないので起動可能 > > > > 異常時 > > 起動完了後フラグ作成 > > 異常shutdownでフラグ残留 > > 次回起動時にフラグがあるので起動NG > > → データリストア後フラグを削除することで機能可能 > > > > これで再度実装検討してみたいと思います。 > > > > > > > > # この微妙なデータの不整合問題は両系停止時にも潜んでそうです > > # 詳細わかりましたまた連絡します PG恐い・・・ > > > > 以上です。 > > > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan -- Yoshiharu Mori <y-mor****@sraos*****> SRA OSS, Inc Japan http://www.sraoss.co.jp TEL: 03-5979-2701 FAX: 03-5979-2702
Fork