Yoshiharu Mori
y-mor****@sraos*****
2011年 10月 10日 (月) 17:36:27 JST
松尾さん 盛です。 すごーくレスが遅くなりました。申し訳ありません。 > 新しいパラメータ (force_start_file) を追加しています。 こちらに関してコメントです。 構築時には、ベースバックアップ取得してスタンバイサーバに 転送することになります。 そのときスタンバイサーバのpg_controldataで取得するデータ状態は in productionとなります。(primaryのデータ状態がそのままコピーされるため) 手動にてスタンバイの起動確認をしない、かつ、force_start_fileを作成せず にpacemakerからPostgreSQLの設定を行って起動すると、新パラメータの機能で、 必ずスタンバイの起動に失敗してしまうことになってしまいますよね？ ここでハマってしまう人が多いような気がします。。 なにかベースバックアップからの初回起動と障害後の起動で区別が つけばよいはずですが。 たとえば、 初期構築時にベースバックアップを取得する際には、 pg_basebackupコマンドを使う方が多いと思います。 pg_basebackupでベースバックアップを取得するときにデフォルトだと pg_xlogは空となります。 そこでpg_xlogが空の場合には、in productionであっても無視して 起動してみるのはいかがでしょうか？ On Thu, 22 Sep 2011 10:10:42 +0900 Takatoshi MATSUO <matsu****@gmail*****> wrote: > 盛さん > 松尾です。 > > 起動抑止のロジック実装しました。 > > https://github.com/t-matsuo/resource-agents/commit/0e4ea2a9644f23096865a002d350f08c487637bf > > 新しいパラメータ (force_start_file) を追加しています。 > このパラメータで、強制起動させたい場合に作るフラグファイルの場所を > 変更できます。 > 正常起動後、フラグファイルは自動削除されます。 > > 以上です。 > > 11/09/21 Yoshiharu Mori <y-mor****@sraos*****>: > > 松尾さん > > > > 盛です。 > > > >> 考えとしては、Primaryがデータをローカルにはコミットしたが、 > >> レプリケーションできないまま落ちた場合の不整合を防ぐのが目的です。 > > > > 了解です。 > > > >> これを考慮すると、8 はどんな状態かわからないので、 > >> 防いだ方がよさそうですね。 > > > > そうですね。 > > > >> 1, 5 の詳しい動作がわからないのですが、 > >> この状態の時は、クライアンから読み書きできる状態なのでしょうか？ > > > > 上記の趣旨からするとクライアントから接続できないので必要ではなさそうですね。 > > > >> # すみません。PostgreSQL自体については初心者なもんで・・・ > > > > いえいえ。将来的にPostgreSQL利用者にとって非常に重要なクラスタツール > > になる思います。私も影ながら応援させて頂きます > > > > 以上です。 > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan -- Yoshiharu Mori <y-mor****@sraos*****>
Fork