[pgpool-general-jp: 570] 縮退運転時の挙動について

[SHIROUZU Hiroaki]

お世話になっております。
白水と申します。

可用性向上だけを目的とした、pgpool-II と 2台のPostgresサーバ
を使った冗長構成において、縮退発生時の挙動について、CGI側での
定番の対処法があれば、お教えください。

構成
 Postgres DBサーバ(8.3.7) * 2台
 CGI(python2.4) + pgpool-IIサーバ(2.2.2) * 1台

現在気になっているのは、1台のDBサーバが落ちた際、
「コネクションが切れる等による一時的なエラー」
に対する対処方法です。

たとえば、上記現象では python の pgモジュールは例外(pg.InternalError)
を返すため、CGIを内部的にトランザクション単位でリトライする対処
を考えましたが、
 http://ml.postgresql.jp/pipermail/pgsql-jp/2004-September/017578.html
のように、例外を返した場合も、縮退したDBに正しくデータがコミット
されている場合があるため、２重登録エラーになる場合が考えられます。
（このあたり、pgpool-IIでは挙動が変化していましたらすみません）

こういう場合の一般的な作法がありましたら、お教えください。

現在のところ、CGI内でのDB操作は、さほど複雑なものではないため、
以下のような案を検討しています。

　0. 事前に commit確認用テーブルを追加作成しておく
  1. begin直後に 上記テーブルに、
       "一意なトランザクションID", "開始ステータス"
　　 といった内容のレコードを挿入
  2. 一連のクエリを処理
　3. 最後に、2で追記したレコードを "処理済ステータス" に変更
　4. commit実行

　1-3において例外が発生した場合は、再コネクション後、1から再実行。
　4 において例外が発生した場合は、再コネクション後、確認テーブル
　でのステータスを確認して、開始ステータスの場合は、1から再実行、
　処理済みステータスの場合は、成功として扱う。

といったイメージです。

本当は、secondaryでの commitエラーはクライアント側に伝わらない形
が理想的なのですが…

-- 
 SHIROUZU Hiroaki
 http://www.ipmsg.org/private/