Yoshiharu Mori
y-mor****@sraos*****
2011年 9月 21日 (水) 11:38:31 JST
Fork松尾さま
盛です。
> ・ cluster state が、shutting down または in production の場合は起動できない。
私の理解を整理すると、
Primaryが正常に起動している場合には、pg_controldataの
Database cluster stateは "in production"になっているはずである。
Primaryが正常に終了した場合には、Database cluster state
は"shut down"になっているはずである。
ここで、Primaryが異常終了した場合には、プロセスは終了したはずであるが、
Dabatase cluster stateは"in production"になっている可能性がある。
この場合には明らかに正常に終了できなかったと判断できる。
また、同様な理由で"shutting down"も正常に終了されなかったことが
予想される。
という理解をしましたが、こちらの理解が正しければ納得しました。
しかし
postgresql-9.1.0/src/bin/pg_controldata/pg_controldata.c
の50行目付近を読むとcluster stateは以下の状態があるようでした。
1 "starting up"
2 "shut down"
3 "shut down in recovery"
4 "shutting down"
5 "in crash recovery"
6 "in archive recovery"
7 "in production"
8 "unrecognized status code"
ここで、4,7以外にもPrimaryを正常に終了できなかったであろうと
思われる状態は、1,5,8もありそうですがこちらも考慮するのはいかがでしょうか？
またStandbyが異常終了してしまった場合に、次回の起動で同様に
pg_controldataは見ないのですか？
(Standbyは問題とならないかもしれませんが。)
> ・ 手動で何かフラグファイルのような物を作れば、強制的に起動可能
> → オンラインバックアップのデータリストア時は、ついでにこのファイル作成が
> 必須になります
あーなるほど、ベースバックアップをとると$PGDATA/global/pg_control
もそのままコピーされるのでフラグが必要なのですね。
勉強になりました。
以上です。
> 盛さま
> 松尾です。
>
> >> migration_threthold はまったく考慮していませんでした。
> >> そもそもMaster リソースの migration_threthold って動くのかが疑問ですが、
> >> ご存じですか。
> >
> > こちらは、私も分からなかったので試しに設定してみたら、スレーブは
> > migration_thretholdが効いてくれました。
> > マスタはpromotion scoreが-1000000になってしまうので、そもそも無理(?)なのかも
> > しれません。
>
> そのようですね。
> Master も migration_threthold で再起動したいという要望は
> 出てきそうですが、必須機能ではないと思っているので、
> 将来のエンハンスメントとしてメモっておきます。
>
>
> >> ●問題事象
> >>
> >> スイッチオーバー時のPriamryのdemote 動作は、
> >> 通常はfast shutdownを実行し、これでPostgreSQLが
> >> 停止しなければ、immediate shutdown に切り替わります。
> >> その後新Primary起動後に旧PrimaryはHot Standbyで起動されます
> >
> > こちらの対策ですが、以下のパラメータを長めにとる
> > で良いのではないかと思いますが。。
> >
> > <parameter name="stop_escalate" unique="0" required="0">
> > <longdesc lang="en">
> > Number of shutdown retries (using -m fast) before resorting to -m immediate
> > </longdesc>
> > <shortdesc lang="en">stop escalation</shortdesc>
> > <content type="integer" default="${OCF_RESKEY_stop_escalation}" />
> > </parameter>
>
> immediate shutdown 無効にするだけなら、長くするだけでよいのですが、
> これはこれでフェイルオーバーに時間がかかってしまうという欠点が
> 出てしまいますし、長くしてもSTONITHで落とされたりすると結局同じ事象が
> 発生してしまいます。
>
> ちなみに、フェイオーバー時間はなるべく短くしたいという
> 要望も個人的に聞くことが結構あります。
>
> > そもそもfast shutdownで停止しない場合というと、バックアップ中または
> > 何かしらの障害時ではないですか？
>
> フェイルセーフの観点で言えば、こういった状況で停止した不整合なデータでの
> 起動も阻止する必要ないですか？
>
>
> > 後者の場合には、それはそれで問題なので、切り離しても良いかと思いました。
> >
> > 前者の場合には、以下の運用対応でも良いかと..
> >
> >> 「バックアップ中にPrimaryが落ちてフェイオーバーした場合、
> >> 旧Primaryのデータを確認し、必要に応じて新Primaryからデータを
> >> リストアする必要がある」
>
> コメントありがとうございます。
>
> その後、いろいろと考えていたのですが、
> 運用で自動バックアップしていた場合、
> バックアップ中にPrimaryが落ちたことに気づくのは難しいのかなと
> 思いました。
>
> Primaryの故障で落ちた場合は大丈夫なのですが、
> NW故障などに引きずられて落ちると、NW回復時に自動で起動してしまいますし。
>
> よって、とりあえず以下の仕様で実装してみたいと思います。
>
> ・ cluster state が、shutting down または in production の場合は起動できない。
> ・ 手動で何かフラグファイルのような物を作れば、強制的に起動可能
> → オンラインバックアップのデータリストア時は、ついでにこのファイル作成が
> 必須になります
>
> もし、これだけは避けて欲しいというコメントもあれば、
> よろしくお願いします。
>
>
> 以上です
> _______________________________________________
> 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