kazuh****@goo*****
kazuh****@goo*****
2014年 2月 27日 (木) 17:03:29 JST
Fork松島さん
ひがしです。お世話になっております。
PostgreSQL単体での再現方法がわかりました。
== 再現手順 ==
1. recovery.confなしでPG起動
→PostgreSQlが普通に(更新可能状態)起動
$ ls $PGDATA/recovery.conf
ls: cannot access /var/lib/pgsql/9.3/data/recovery.conf: そのようなファイルやディレクトリはありません
$ pg_ctl start
2. immediateで停止
$ pg_ctl stop -m i
3. recovery.confを作成しPG起動
$ ls $PGDATA/recovery.conf
/var/lib/pgsql/9.3/data/recovery.conf
$ cat $PGDATA/recovery.conf
standby_mode = 'on'
primary_conninfo = 'host=192.168.30.100 port=5432 user=repuser application_name=pm01 keepalives_idle=60 keepalives_interval=5 keepalives_count=5'
restore_command = '/bin/cp /var/lib/pgsql/9.3/data/pg_arch/%f %p'
recovery_target_timeline = 'latest'
$ pg_ctl start
→Slaveで起動するはずだがいつまでたっても起動しない！！
→psql -lを実行すると以下エラーとなる
psql: FATAL: the database system is starting up
===========
一度↑こうなるとrecovery.confありのままでは
PostgreSQL再起動をしても起動しないようです
一度recovery.confなしで起動し、正常停止(pg_ctl stop)を
すると、再びrecovery.confありで起動するようになります。
PG-REXの場合(Pacemakerを使用した場合)、restart_on_promoteがtrueかつ
stop_escalateが0の場合に、以下の操作が実施されるため、上記再現手順を
踏んでしまうようです。
(私の環境PM1.0+Heartbeat3でもrestart_on_promoteをtrueにしたら再現しました)
1. Master側 Pacemaker起動
内部的には
recovery.confありでPG起動後、promoteのためPGをimmediateで停止し
recovery.conなしで起動する
→これが再現手順1にあたる
2. Master側 Pacemaker停止
内部的には
immediateでPG停止
→これが再現手順2にあたる
3. 再度Master側 Pacemaker起動
内部的には
recovery.confありでPG起動
→これが再現手順3にあたる。PGが起動しないのでタイムアウトエラー発生。
> 気になるのは、Pacemaker 1.0とCorosync 1.4の組み合わせだと問題がでないことです。
> 全く同じRAを使っているのですが... タイミングとか偶然とか、そういったものだと気持ちが悪いですね。
上記再現手順によると、restart_on_promoteの値や、PGの操作を手で行ったかどうかが
カギになりそうです。
取り急ぎ以上です。
2014/02/27 (Thu) 15:53, "Takehiro Matsushima" <takeh****@gmail*****> wrote:
> ひがしさん
>
> 松島です。
> お忙しいところありがとうございます。
>
> immediate stopが鍵ということでしたので、試してみましたところ、
> 私の環境ではほぼ確実にダメになりました。
>
> 異常系のログのみ採取してみました。
>
> まず正常に立ち上がるよう、一旦通常通りにrecovery.confを削除して
> service postgresql-9.3 start/stopをし、(動かない環境を作り出せる)Pacemakerでstart/stopしました。
> ですので、最初はSlaveで上がってその後promote、しばらく後にstopしています。(添付tar内1st--(略).log)
>
> 続いてpacemakerをもう一度立ち上げていますが、件のエラーでstartが失敗しているログです(添付tar内2nd--(略).log)
>
>
> ひがしさんのアドバイスどおりstop_escalateをとりあえず1にしてみましたところ、不具合は回避されるようになりました。
> ひとまずはこれで別の作業も進められそうです。ありがとうございます。
>
>
> 気になるのは、Pacemaker 1.0とCorosync 1.4の組み合わせだと問題がでないことです。
> 全く同じRAを使っているのですが... タイミングとか偶然とか、そういったものだと気持ちが悪いですね。
>
>
> お忙しいところお時間を割いていただきまして、ありがとうございます。
> 私のほうでも引き続き調査をしてみます。
>
>
> 2014年2月27日 15:02 <kazuh****@goo*****>:
> > 松島さん
> >
> > ひがしです。お世話になっております。
> >
> > 私の環境で、PostgreSQL単体で再現しました。
> > PostgreSQL単体でも再現したことから、おそらくPostgreSQLのバグではないかと
> > 思います。
> >
> >
> > 以下手順でPostgreSQLをリカバリモード起動→promote→immediate停止を繰り返すと
> > 松嶋さん環境と同様の事象(PostgreSQLが起動しない)が発生しました。
> >
> > $ vim /var/lib/pgsql/9.3/data/recovery.conf →手動でリカバリモードに
> > $ pg_ctl start →リカバリモードで起動
> > $ pg_ctl promote →Masterに昇格
> > $ pg_ctl stop -m i →immediateで停止
> > $ mv recovery.done recovery.conf → 再び手動でリカバリモードに
> > $ pg_ctl start →起動しない場合あり！！
> >
> > 起動しない場合は、psqlで接続しようとすると以下のようなメッセージでエラーになります。
> > psql: FATAL: the database system is starting up
> > いつまで待ってもこの状態が続きます。
> >
> > ただし、必ず再現するわけではなく、正常に起動する場合もありました。
> > (何回も繰り返しているうちに今現在は再現しなくなってしまいました。
> > debugログを取りたかったのですが・・・)
> >
> >
> > PostgreSQLの観点から調査したいので、もし、可能でしたら、PostgreSQLのログレベルを
> > debug5にして再現させていただけないでしょうか？
> > (log_min_messagesをdebug5に設定しPostgreSQL再起動)
> >
> >
> >
> > なお、推測ですが、immediateによるPG停止後に発生するようなので、
> > pgsql RAのstop_escalateを10など、1以上の値にしimmediateでの停止を避けると、
> > 暫定的に回避できるかもしれません。
> > (immediateによる停止の前にfastによる停止をし、stop_escalate秒
> > 待つようになります。)
> >
> > またはPostgreSQL9.2系をご使用いただくのも手かと思います。
> >
> >
> > 今後も調査を続けますが、現時点では以上です。
> > よろしくお願いいたします。
> >
> >
> > 2014/02/27 (Thu) 10:41, "Takehiro Matsushima" <takeh****@gmail*****> wrote:
> >> 松島です。更に連投申し訳ございません。
> >>
> >> 早とちりだったようです。
> >> Pacemaker stopかstartかは無関係でした。
> >> コミュニティ版を使ってinitdbしたらその後は発生しません。
> >>
> >> Nightly(2月20日版)のPacemaker+Corosyncを使うとその後から動かなくなりました。
> >> コミュニティ版に戻しても、initdbして作りなおさないと動きませんでした。
> >>
> >> resource-agentsだけはNightlyを共通して使っていますので、RAのせいではないと思いますが...
> >>
> >> #本番環境にはコミュニティ版を使用していくつもりではいます。
> >>
> >>
> >> 2014年2月27日 7:45 Takehiro Matsushima <takeh****@gmail*****>:
> >> > お世話になっております、松島です。
> >> > 連投申し訳ございません。
> >> >
> >> > 更に追試しました。
> >> > Nightly版からコミュニティ版に変更しても現象に変化はありませんでした。
> >> > 以下コミュニティ版で、かつ単一ノードのみを使って実験しています。
> >> >
> >> > 1. Pacemaker stopの状態で...
> >> > 1.1. PostgreSQL9.3.3でinitdbしてバックアップしていたデータを注入(150MBくらいのSQL)
> >> > 1.2. Pacemaker start/stopを繰り返す
> >> > 1.3. 現象の再現
> >> >
> >> > 2. Pacemaker startの状態で...
> >> > 2.1. (1.1.)と同じ作業
> >> > 2.2. (1.2.)と同じ作業
> >> > 2.3. 現象再現せず
> >> > 2.4. 2ノード構成でフェイルオーバー→完全停止→1ノード運転→2ノード運転を繰り返す
> >> > 2.4. 現象再現せず
> >> >
> >> > という結果となりました。
> >> > 取り急ぎ報告とさせていただきます。
> >> >
> >> > --
> >> > Regards,
> >> > Takehiro Matsushima
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Takehiro Matsushima
> >>
> >> _______________________________________________
> >> Linux-ha-japan mailing list
> >> Linux****@lists*****
> >> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
> >>
>
>
>
> --
> Regards,
> Takehiro Matsushima
>