[pgpool-general-jp: 618] Re: オンラインリカバリ時のBackendErrorについて

2009年 9月 3日 (木) 16:59:29 JST

TO:石井様

お世話になっております。田辺です。
頂いたパッチをもとに、

　PGPool-II v2.2.4 + パッチ

にて、オンラインリカバリの動作確認が取れました。
ご回答ありがとうございました。

以上


Date:Thu, 03 Sep 2009 13:00:10 +0900 (JST)
From：Tatsuo Ishii <ishii ＠ sraoss.co.jp>様
To：pgpool-general-jp ＠ sraoss.jp,r-tanabe ＠ nsat.co.jp
Cc：--
> 詳細なレポートありがとうございます。石井です。
> 
> > お世話になっております。田辺です。
> > 先日のメールについて補足させてください。
> > 
> > child.c:Req_info->conn_counterに注目し、child.c:connection_count_
down()
> > の直後にReq_info->conn_counterの値をpool_log()を使ってログ出力させた
とこ
> > ろ、値がマイナス(-1)になっていました。
> > 
> > ここから推測すると、このために、オンラインリカバリ時に
> > recovery.c:wait_connection_closed()内
> >                 if (Req_info->conn_counter == 0)
> > が満たされず、クライアントのクローズ待ちがタイムアウトしているように
見え
> > ます。
> > 
> > レプリケーションしているPostgreDBの停止には、
> > 
> > 　(a) pg_ctl stop -D /usr/local/pgsql/data
> > 　(b) pg_ctl stop -D /usr/local/pgsql/data -s -m fast
> > 
> > を使いました。本事象は、両方で発生するのですが、(b)の方がより発生し
やす
> > いです。
> > 
> > そこで質問なのですが、
> > 　(1) カウンタがマイナス値になることは想定通りの動作でしょうか？
> 
> いえ。
> 
> > 　(2) 上記(1)の回答で”想定通りでない”場合、回避方法はありますでし
ょう
> > か？
> 
> 必ずしもリカバリ中にこの現象が発生しないのだとすると、シグナル割り込み
> などのタイミングの問題で、どこかでカウンタを余計に減算していると思われ
> ます。そうなると、ソースコードの修正以外には対応方法はないと思います。
> 
> > 　(3) Postgresの停止として、-m fastの利用は許されていないのでしょう
か？
> 
> いえ、そんなことはありません。
> 
> > 　(4) カウンタがマイナス値になった場合の検出方法やリセット方法はあり
ます
> > でしょうか？
> 
> カウンタを余計に減算していそうな箇所があったので、修正パッチを作ってみ
> ました。可能であれば、添付のパッチを試してみていただけますでしょうか?
> 
> > 　質問を書き連ねて申し訳ありませんが、ご教授いただけないでしょうか。
> > 
> > 　以上、よろしくお願いします。
> > 
> > 
> > 
> > 
> > Date:Fri, 21 Aug 2009 15:08:34 +0900
> > From：Ryoichi TANABE <r-tanabe ＠ nsat.co.jp>様
> > To：pgpool-general-jp ＠ sraoss.jp
> > Cc：--
> > > 初めまして。田辺と申します。
> > > 掲題の件に関し質問させていただきたくメールしました。
> > > 
> > > オンラインリカバリの 2ndステージに入ったところで、クライアントプロ
グラ
> > ム
> > > が、DB接続完了待ちになり、リカバリタイムアウト(recovery_timeout)ま
で処
> > 理
> > > が戻りません。オンラインリカバリは、タイムアウトしたところで
> > BackendError
> > > エラーで失敗します。
> > > 
> > > PGPool側での2nd ステージ開始時のクライアント接続の終了待ち　と
> > > クライアントプログラムでのDB接続完了待ち　とが
> > > 互いに待ち続けているように見えています。
> > > 
> > > v2.2.2ではこのように互いに待ち続けているようなことはありませんでし
た。
> > > 
> > > 対処法などございましたらご回答の程よろしくお願いします。
> > > 
> > > 
> > > 
> > > 
> > > ※PGPoolのログより抜粋
> > > 2009-08-20 14:08:22 LOG:   pid 27568: starting 2nd stage
> > > 2009-08-20 14:14:25 ERROR: pid 27568: wait_connection_closed: 
existing 
> > > connections did not close in 360 sec.
> > > 2009-08-20 14:14:25 ERROR: pid 27568: start_recovery: timeover for 
> > > waiting connection closed
> > > 
> > > ※pgpool.confより抜粋
> > > recovery_timeout = 360
> > > client_idle_limit_in_recovery = 240
> > > 
> > > ※クライアントプログラムはPythonで作成しいます
> > > ※クライアントプログラムは、常駐プロセスで、
> > > 　　pgdb.connect() -> cursor.executemany() -> db.commit() -> db.
close()
> > > 　を繰り返しています。pgdb.connect()で処理が止まっている状態になり
ます
> > > ※システム構成情報
> > > 　PGPool-II  : v2.2.3
> > > 　PostgreSQLl: 8.3.7
> > > 　OS         : CentOS5
> > > 　Python     : 2.5.1
> > > 　DB-API     : PyGreSQL-4.0
> > > 　２ノードのレプリケーションモード
> > > 
> > > 以上
> > > -----------
> > > 田辺亮一
> > > _______________________________________________
> > > pgpool-general-jp mailing list
> > > pgpool-general-jp ＠ sraoss.jp
> > > http://www.sraoss.jp/mailman/listinfo/pgpool-general-jp
> > 
> > 
> > -----------
> > 田辺亮一
> > _______________________________________________
> > pgpool-general-jp mailing list
> > pgpool-general-jp ＠ sraoss.jp
> > http://www.sraoss.jp/mailman/listinfo/pgpool-general-jp
> 


-----------
田辺亮一