大渕昭夫
ohbuc****@m2j*****
2015年 10月 8日 (木) 10:51:17 JST
Fork山内さん
こんにちは。
大渕です。
ご返信ありがとうございます。
また、丁寧な解説ありがとうございます。本当に助かります。
migretion-thresholdは以下のように1となっているようです。
rsc_defaults $id="rsc-options" \
resource-stickiness="INFINITY" \
migration-threshold="1"
引き続き勉強していこうと思います。
以上、よろしくお願いいたします。
On 2015/10/07 20:33, renay****@ybb***** wrote:
> 大渕さん
>
> こんばんは、山内です。
>
>> 本件の挙動について考えてみたのですが、、、
>> 片肺状態でop monitor interval="2s" role="Master"
>> timeout="60s"
>> on-fail="restart" の
>> timeout60秒に到達したのでpgsqlをrestartしたけれど、unknownerrorでstopに
>> なった
>> という認識で合っておりますでしょうか。
>
> CRMの詳細を見ていないのですが・・・
>
> Pacemakerのデフォルト設定（指定していない場合）では、リソースの故障管理回数の閾値(migration-threshold)は１回になっていますので、
> 故障(monitor故障）が許されるのは１回になります。
>
> また、on-fail="restart"を指定している場合には、そのopでエラーが起きると、
> そのリソースのstop->startの動作となります。
>
> よって、今回の場合、
> monitorで１回故障が起きたので、stopした。
>
> ＃restart(stop後にstart)する為には、故障管理回数の閾値が２以上の必要があります。
>
> となっているはずです。
>
> 以上です。
>
>
>
> ----- Original Message -----
>> From: 大渕昭夫 <ohbuc****@m2j*****>
>> To: renay****@ybb*****; linux****@lists*****
>> Cc:
>> Date: 2015/10/7, Wed 18:51
>> Subject: Re: [Linux-ha-jp] PostgreSQLのストリーミングレプリケーションのフェイルオーバーの原因について
>>
>> 山内さん
>>
>> 大渕です。
>> ご返信ありがとうございます！
>>
>> monitorのタイムアウトの伸長も検討してみます。
>>
>> そうですね。そもそものPostgreSQLの設定全般に関して見直しているところです。
>> PostgreSQLのログも有効になっていなかったので。
>>
>> マシンは物理サーバー2台構成なので、CPUの制限等はないと思われます。
>>
>> また、CRMの内容についてももう一度勉強しております。
>>
>> 本件の挙動について考えてみたのですが、、、
>> 片肺状態でop monitor interval="2s" role="Master"
>> timeout="60s"
>> on-fail="restart" の
>> timeout60秒に到達したのでpgsqlをrestartしたけれど、unknownerrorでstopに
>> なった
>> という認識で合っておりますでしょうか。
>>
>> 以上、よろしくお願いいたします。
>>
>> On 2015/10/07 17:03, renay****@ybb***** wrote:
>>> 大渕さん
>>>
>>> こんにちは、山内です。
>>>
>>> 場合によっては、monitorのタイムアウトの伸長は有効だと思います。
>>>
>>> ただし、負荷試験などで、実際にかかる負荷をある程度見極める必要があると思います。
>>> また、仮想マシンで構成されている場合などは、CPUなどに制限をかけている場合は、その制限を増やすなども
>>> 有効な場合があります。
>>>
>>> 以上です。
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: 大渕昭夫 <ohbuc****@m2j*****>
>>>> To: linux****@lists*****
>>>> Date: 2015/10/2, Fri 10:40
>>>> Subject: Re: [Linux-ha-jp] PostgreSQLのストリーミングレプリケーションのフェイルオーバーの原因について
>>>>
>>>>
>>>> 度々すいません。
>>>> 大渕です。
>>>>
>>>> 昨日の問い合わせ内容なんですが、CRMの設定は以下のようになっていました。
>>>>
>>>> primitive pgsql ocf:heartbeat:pgsql \
>>>> params pgctl="/usr/local/pgsql-9.2.4/bin/pg_ctl"
>>> psql="/usr/local/pgsql-9.2.4/bin/psql"
>>> pgdata="/var/lib/pgsql/data/" start_opt="-p
>> 5432" rep_mode="sync"
>>> node_list="ptdb01.localdomain ptdb02.localdomain"
>>> restore_command="cp /var/lib/pgsql/data/pg_archive/%f %p"
>>> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5
>>> keepalives_count=5" master_ip="172.16.1.3"
>> stop_escalate="0" \
>>>> op start interval="0s" timeout="60s"
>> on-fail="restart" \
>>>> op monitor interval="7s" timeout="60s"
>> on-fail="restart" \
>>>> op monitor interval="2s" role="Master"
>> timeout="60s"
>>> on-fail="restart" \
>>>> op promote interval="0s" timeout="60s"
>> on-fail="restart" \
>>>> op demote interval="0s" timeout="60s"
>> on-fail="stop" \
>>>> op stop interval="0s" timeout="60s"
>> on-fail="block" \
>>>> op notify interval="0s" timeout="60s"
>>>>
>>>> 16:15の時点ではフェイルオーバー後なので片肺状態だったと思うのですが、その時に重いクエリが実行されて停止処理のタイムアウト値
>>> 60sに到達したので自ノードのpostgresプロセスを強制終了したということになりますでしょうか。
>>>> 片肺状態でもタイムアウト値に到達するとpostgresプロセスの強制終了を実行してしまうのでしょうか。
>>>>
>>>> その場合この設定の60sを300sなどに修正すると重いクエリに耐えられる状態になりますでしょうか。
>>>>
>>>> いまさらな質問で恐縮ですが、お時間あるときにアドバイスいただけますと助かります。
>>>>
>>>> 以上、よろしくお願いいたします。
>>>>
>>>> On 2015/10/01 19:25, 大渕昭夫 wrote:
>>>>
>>>> 各位
>>>>> お世話になっております。
>>>>> 大渕と申します。
>>>>>
>>>>> 前回こちらで問い合わせさせてもらったサーバーについて、また質問させてくだ さい。
>>>>>
>>>>> 「PostgreSQL9.1ストリーミングレプリケーション対応リソースエー ジェント」 を参考に構築したサーバーです。
>>>>>
>>>>> 環境は以下の通りです。
>>>>> CentOS5
>>>>> PostgreSQL9.2.4
>>>>> Pacemaker1.0.13-1.1
>>>>> Master/Slave構成
>>>>> 以上
>>>>>
>>>>> 前回、松島さんにアドバイスいただいた内容を参考に、PostgreSQLの max_connectionsの100を1000に上げて
>>> work_memを32MBから4MBに下げてからデー タ同期してHA構成に戻したのですが、本日以下のような事象が発生しました。
>>>>> 14:08 エラーがマスター機で発生、PostgreSQL停止/フェイルオーバー発生
>>>>> 16:15 エラーがマスター機で発生、PostgreSQL停止 DBアクセス不可とユー ザーから連絡
>>>>> 16:15 サーバーにアクセスしたところ以下の状態
>>>>>
>>>>> Node Attributes:
>>>>> * Node ptdb01.localdomain:
>>>>> + default_ping_set : 100
>>>>> + master-pgsql:1 : -INFINITY
>>>>> + pgsql-data-status : LATEST
>>>>> + pgsql-status : STOP
>>>>> + ptdb02.localdomain-eth2 : up
>>>>> + ptdb02.localdomain-eth3 : up
>>>>> * Node ptdb02.localdomain:
>>>>> + default_ping_set : 100
>>>>> + master-pgsql:0 : -INFINITY
>>>>> + pgsql-data-status : DISCONNECT
>>>>> + pgsql-status : STOP
>>>>> + ptdb01.localdomain-eth2 : up
>>>>> + ptdb01.localdomain-eth3 : up
>>>>>
>>>>> Failed actions:
>>>>> pgsql:0_monitor_2000 (node=ptdb02.localdomain, call=16, rc=-2,
>>> status=Timed Out): unknown exec error
>>>>> pgsql:1_monitor_2000 (node=ptdb01.localdomain, call=22, rc=-2,
>>> status=Timed Out): unknown exec error
>>>>> 16:25 両ノードを停止、マスター機のみで起動して取り急ぎ復旧
>>>>> 以上
>>>>>
>>>>> 14:08と16:15に重いクエリを実行したそうなので、work_memを4MBに下げたため にPostgreSQLに問題が起きて
>>> unknown exec errorになったのではないかと思っ ています。
>>>>> ha-logを添付させていただきますので、本件の原因と今後の再発防止策につい て、ご教示いただけると大変ありがたいです。
>>>>>
>>>>> 以上、よろしくお願いいたします。
>>>>>
>>>>> On 2015/08/26 11:45, Takehiro Matsushima wrote:
>>>>>
>>>>> 大渕さん
>>>>>> 松島です。
>>>>>> OSC 2015 Tokyo/Fallでお会いできることを楽しみにしております！
>>>>>>
>>>>>>
>>>>>> Webサーバー(正確にはAPサーバー)がDBに対していくつのコネクションを張るかということを本当は計算しておく必要があります。
>>>>>> APあたりのコネクション数、AP台数、内部的に生じるコネクション数、通常管理用に必要なコネクション数、DBのリソース、APのリ
>>> ソースなどから値を決めていくことになるとおもいます。
>>>>>> pg_isreadyですが、現状のpgsql RAは未対応ですので、RAを改修してみるのも楽しいと思います。
>>>>>>
>>>>>> フェイルオーバーの検知ですが、私はMailTo RAを使用してメール通知をするようにしています。
>>>>>> Zabbix等の監視ソリューションでプロセス監視したりカスタムコマンドで監視したり、もしくはSNMPを使用するのもよいと思いま
>>> す。
>> 時間的に余裕があるのでしたらいろいろ試してみて、最終的に決定していただくのがもちろん最善だとは思いますが、即席でということでした
>>> らとりあえずMailTo
>>>>>> RAが使いやすい印象です。
>>>>>> ぜひお試しください。
>>>>>>
>>>>>> 以上よろしくお願いいたします。
>>>>>>
>>>>>> ----
>>>>>> Takehiro Matsushima
>>>>>>
>>>>>> 2015年8月26日 10:32 大渕昭夫 <ohbuc****@m2j*****>:
>>>>>>
>>>>>> 松島さん
>>>>>>> お世話になっております。
>>>>>>> 大渕です。
>>>>>>>
>>>>>>> ご無沙汰してます！
>>>>>>> また次回のOSCに遊びに行こうかと思ってます。
>>>>>>>
>>>>>>> 早速の返信ありがとうございます。
>>>>>>> 大変助かります。
>>>>>>>
>>>>>>> max_connectionsの設定がデフォルトの100だったのが問題だったんですね。
>>>>>>> WEBサーバー側の設定とDB側の設定に相違があったようなので、今回は
>>>>>>> max_connectionsを適切な数値に合わせる方向で対処し ようと思います。
>>>>>>> ちなみにsuperuser_reserved_connectionsはコメントアウトされていました。
>>>>>>>
>>>>>>> 今使っているサーバー自体が来年あたりにはリプレイスになるかもしれませんの
>>>>>>> で、その際にはpg_isreadyも調べてみようかと思いま す。
>>>>>>>
>>>>>>> ところで、今回たまたまフェイルオーバーしていたことに気づいたのですが、み
>>>>>>> なさんはどのようにフェイルオーバーを検知しているのでしょう か。
>>>>>>>
>>>>>>> 以上、よろしくお願いいたします。
>>>>>>>
>>>>>>> On 2015/08/26 2:17, Takehiro Matsushima wrote:
>>>>>>>
>>>>>>> 大渕さん
>>>>>>>> お世話になっております、松島です。
>>>>>>>> ご無沙汰しております。
>>>>>>>>
>>>>>>>>
>> PostgreSQLのストリーミングレプリケーションにおいて、スレーブはマスターに対して常時接続を行っていたと思いますの
>>> で、max_connectionsを使い切った状態でレプリケーションを新規に開始しようとしたのでなければ、問題ないはずで
>>> す。
>>>>>>>> max_wal_senders :
>>>>>>>>
>> https://www.postgresql.jp/document/9.2/html/runtime-config-replication.html
>>>>>>>> max_connections および superuser_reserved_connections :
>>>>>>>>
>> https://www.postgresql.jp/document/9.2/html/runtime-config-connection.html
>>>>>>>>
>> ログのメッセージからはRAが死活監視のためにPostgreSQLに接続しようとして拒否されていると私は推測しました。
>>>>>>>> RAはmonitorアクションでpsqlで接続し、SQL(デフォルトは SELECT now()
>>> )を実行して成否を判断しています。
>> したがって、max_connectionsを使い切っているときに死活監視が走ると、"Connection error
>>> (connection
>>>>>>>> to the server went bad and the session was not
>> interactive)
>>> occurred
>>>>>>>> while executing the psql
>> command."と言われてしまうということになります。
>>>>>>>> ところで、この状況であってもsuperuser_reserved_connectionsで予約してあれば、
>>> monitor_userにスーパーユーザーの名前を書いておくことで死活監視は成功するものと思われます。
>> 管理作業の都合もありますのでsuperuser_reserved_connectionsは2以上必要ですが、運用や管理に
>>> 合わせて最終的な数を決定する必要があります。
>> ただし、スーパーユーザー(postgresユーザなど)を死活監視等で使用する場合にはpg_hba.confなどを適切に設
>>> 定しなくてはなりませんのでご注意ください。
>>>>>>>> 余談ですがPostgreSQL
>>> 9.3からは接続ステータスを判別できるpg_isreadyというコマンドが使えるようになりました。
>> https://www.postgresql.jp/document/9.3/html/app-pg-isready.html
>> 試してみてはいないのですが、monitorアクションでこれも使えるようにRAを変更すればこういった事例にも対応できるかも
>>> しれません。
>>>>>>>> ----
>>>>>>>> Takehiro Matsushima
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2015年8月25日 18:50 大渕昭夫 <ohbuc****@m2j*****>:
>>>>>>>>
>>>>>>>> 各位
>>>>>>>>> お世話になっております。
>>>>>>>>> 大渕と申します。
>>>>>>>>>
>>>>>>>>> 2年ほど前に「PostgreSQL9.1ストリーミングレプリケーション対応リソースエー
>>> ジェント」を参考に構築し、サーバーの設置場所の移動
>>>>>>>>> の際など何度かこちら のメーリングリストにお世話になりまして、おかげさまで無事に稼働していたの
>>> ですが、昨夜アクセスが集中する事態が発生した
>>>>>>>>> ところ、フェイルオーバーし たようです。
>>>>>>>>>
>>>>>>>>> フェイルオーバーした原因を教えていただきたく、メールさせていただきました。
>>>>>>>>>
>>>>>>>>> ha-logを添付いたしますので、お力を貸していただけると大変ありがたいです。
>>>>>>>>>
>>>>>>>>> 環境は以下の通りです。
>>>>>>>>> CentOS5
>>>>>>>>> PostgreSQL9.2.4
>>>>>>>>> Pacemaker1.0.13-1.1
>>>>>>>>> Master/Slave構成
>>>>>>>>> 以上
>>>>>>>>>
>>>>>>>>> また、ha-logの7028行目あたりに以下のような表示がありましたので、この時間
>>> にerrorが発生したことが原因でフェイルオーバーする
>>>>>>>>> 流れになったように思わ れます。
>>>>>>>>>
>>>>>>>>> Aug 24 22:15:37 ptdb01.localdomain lrmd: [7455]:
>> info: RA
>>> output:
>>>>>>>>> (pgsql:0:monitor:stderr) psql: FATAL: sorry, too
>> many
>>> clients already
>>>>>>>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR:
>>> PostgreSQL template1 isn't
>>>>>>>>> running
>>>>>>>>> pgsql(pgsql:0)[21016]: 2015/08/24_22:15:37 ERROR:
>>> Connection error
>>>>>>>>> (connection to the server went bad and the session
>> was not
>>> interactive)
>>>>>>>>> occurred while executing the psql command.
>>>>>>>>> Aug 24 22:15:37 ptdb01.localdomain crmd: [7458]:
>> info:
>>> process_lrm_event:
>>>>>>>>> LRM operation pgsql:0_monitor_2000 (call=16, rc=1,
>>> cib-update=50710,
>>>>>>>>> confirmed=false) unknown error
>>>>>>>>> 以上
>>>>>>>>>
>>>>>>>>> Master側のサーバー自体はダウンしておりません。/var/log/messagesの該当時
>>> 刻には特にログはなかったので問題なく動いて
>>>>>>>>> いるように思われます。
>>>>>>>>>
>>>>>>>>> アクセスが長時間集中したのでMaster側のPostgreSQLの設定にあった
>>> max_connections=100の状態が続いてしま
>>>>>>>>> い、Slave側の通信に応答しなかった
>> ためフェイルオーバーしてしまったのではないかと予想してみたのですが、そう
>>> いったことは考えられますで しょうか。
>>>>>>>>> 以上、お忙しいところ恐縮ですが、よろしくお願いいたします。
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Linux-ha-japan mailing list
>>>>>>>>> Linux****@lists*****
>>>>>>>>>
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>>>>>
>>> _______________________________________________
>>>>>>>> Linux-ha-japan mailing list
>>>>>>>> Linux****@lists*****
>>>>>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>>>>
>>>>>>>>
>>> _______________________________________________
>>>>>>> Linux-ha-japan mailing list
>>>>>>> Linux****@lists*****
>>>>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>>>
>>> _______________________________________________
>>>>>> Linux-ha-japan mailing list
>>>>>> Linux****@lists*****
>>>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>> Linux-ha-japan mailing list Linux****@lists*****
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>> _______________________________________________
>>>> Linux-ha-japan mailing list
>>>> Linux****@lists*****
>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux****@lists*****
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux****@lists*****
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan