大渕昭夫
ohbuc****@m2j*****
2015年 10月 2日 (金) 10:40:32 JST
Fork度々すいません。
大渕です。
昨日の問い合わせ内容なんですが、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
-------------- next part --------------
HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...
下載