大渕昭夫
ohbuc****@m2j*****
2015年 10月 1日 (木) 19:25:17 JST
Fork各位
お世話になっております。
大渕と申します。
前回こちらで問い合わせさせてもらったサーバーについて、また質問させてくだ
さい。
「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
>
-------------- next part --------------
$B%F%-%9%H7A<00J30$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...
$B%U%!%$%kL>(B: ha-log.zip
$B7?(B: application/x-zip-compressed
$B%5%$%:(B: 23455 $B%P%$%H(B
$B ＠ bL@(B: $BL5$7(B
下載