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

[Tatsuo Ishii]

石井です。

当時は確かにそうでしたが、現在のpgpool-IIでは、縮退を起したときには、
生きている方のDB へのトランザクションもアボートされるため、CGI側で常に
リトライするでほとんどの場合問題ないと思います。

# ちなみに、クライアント側で明示的なトランザクションを発行しなくても、
# pgpool-II側で勝手にトランザクションにします。

唯一問題になるのは、あるノードでコミットに成功したが、別のノードで失敗
した場合。こういうことはめったに起きないと思いますが、もし起きてしまう
と、すでにコミットしたデータは取り消せないので、リトライすると不都合が
起ることもあると思います。

こういったケースの場合、CGI側でリトライの可否が判断できるように、特定
のエラーメッセージをpgpool-IIがクライアント側に返すようにすることはで
きると思います。そうした方が良いですか？

# 2相コミットを使えば解決できるのでは、と思う方もいらっしゃると思いま
# すが、2相コミットでもpre commitではなくて最後のコミットに失敗すれば
# 同じ問題が起きます。
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> お世話になっております。
> 白水と申します。
> 
> 可用性向上だけを目的とした、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/
> _______________________________________________
> pgpool-general-jp mailing list
> pgpool-general-jp ＠ sraoss.jp
> http://www.sraoss.jp/mailman/listinfo/pgpool-general-jp