Takatoshi MATSUO
matsu****@gmail*****
2011年 10月 12日 (水) 13:53:22 JST
盛さん 松尾です 2011年10月10日17:36 Yoshiharu Mori <y-mor****@sraos*****>: > 松尾さん > > 盛です。 > > すごーくレスが遅くなりました。申し訳ありません。 いえいえ。 コメント頂けるだけでも助かります。 >> 新しいパラメータ (force_start_file) を追加しています。 > > こちらに関してコメントです。 > > 構築時には、ベースバックアップ取得してスタンバイサーバに > 転送することになります。 > そのときスタンバイサーバのpg_controldataで取得するデータ状態は > in productionとなります。(primaryのデータ状態がそのままコピーされるため) > > 手動にてスタンバイの起動確認をしない、かつ、force_start_fileを作成せず > にpacemakerからPostgreSQLの設定を行って起動すると、新パラメータの機能で、 > 必ずスタンバイの起動に失敗してしまうことになってしまいますよね？ そうですね。 > ここでハマってしまう人が多いような気がします。。 本家コミュニティなら、ログ見ろって言われそうですが・・・ > なにかベースバックアップからの初回起動と障害後の起動で区別が > つけばよいはずですが。 > > たとえば、 > 初期構築時にベースバックアップを取得する際には、 > pg_basebackupコマンドを使う方が多いと思います。 > pg_basebackupでベースバックアップを取得するときにデフォルトだと > pg_xlogは空となります。 > そこでpg_xlogが空の場合には、in productionであっても無視して > 起動してみるのはいかがでしょうか？ pg_basebackup でとったデータはpg_xlogは空かもしれませんが、 今回のRAを使う場合、xlog は何らかの形で共有している可能性が高いので、 結局起動時は空ではない可能性が高いのではないでしょうか。 もしユーザがハマらないようにしたいというのが目的なら、 pgsql-status の属性を STOP:invalid のような表示にしてあげてもよいかなと 思います。 さらに、STOP:invalid になったら、特別なリソースを起動し、その中でrsync でデータ再同期を始め、 同期完了後にフェイルカウントクリアするという設計も面白いかもしれません。 ※お互い壊れたデータをrsyncすると悲惨なことになるのでここまでフルオート化するのは結構恐いですが・・・
Fork