[pgsql-jp: 34032] Re: pgpool-2.1においてコミット時にセカンダリがダウンした際の不具合？について

[Tatsuo Ishii]

石井です．

> > もしpgpoolで対応するとすると，マスタが正常コミット，セカンダリがエラー
> > になった場合にはアプリケーションにエラーを通知せず，黙ってセカンダリを
> > 切り放すしかないのですが，それはそれで不都合かもしれないと思ってしまい
> > ます．そのあたり，いかがでしょう？
> 
> この件も含めまして、現行のpgpoolにおける縮退運転モードへの移行時の
> 動作につきまして、ちょっと私なりに勝手に考えてみましたので、
> 一つの意見としてお聞きいただければ幸いです。
> もし見当違いなことを言っていましたら、その際は申し訳ございませんが、
> 聞き流していただくか、またはご指摘いただければと存じます。
> 
> 今回pgpoolの動作検証を行っていた際に、一つ疑問に思った点があります。
> 
> まず、マスタもしくはセカンダリのPostgreSQLデータベースが停止した際に
> pgpoolがその状況を検知して縮退運転モードに移行しますが、
> その際にクライアント側にエラーが通知されて接続が切断されます。
> 
> 幾つかのエラーケースを試した限りでは、概ね次のようになりました。
> ・マスタ側だけを停止した場合は、エラーが2回発生する。
> ・セカンダリ側だけを停止した場合は、エラーが1回発生する。
> ・接続中だったセッションは、エラーによって接続を切断される。
> 
> そこで私は、そもそもこのエラーをPostgreSQLデータベースに接続する
> クライアントアプリケーション側に通知する必要があるのだろうか？
> と疑問に思い始めました。
> 
> pgpoolを使用することにより、物理的に2つのPostgreSQLデータベースで
> 論理的に1つのPostgreSQLデータベースを構成することができ、
> それによって負荷分散や冗長化などのメリットを実現しています。
> pgpoolを導入することはシステム環境レベルでの検討項目であり、
> 本来はクライアントアプリケーション自体がpgpoolの仕様を意識する
> 必要はないものと考えています。
> pgpoolの公式ページにおいてpgpoolのメリットの1番目に
> 『アプリケーションの変更の必要がありません』とありますが、
> まさしくこのメリットはそのことを指しているものと考えます。
> http://www2b.biglobe.ne.jp/~caco/pgpool/
> 
> よって、pgpoolが縮退運転モードに移行する際は、
> クライアントアプリケーションに対してエラーを通知して
> 接続を切断する必要はないのではないでしょうか。
> 
> たとえマスタもしくはセカンダリが停止したとしても、
> その代わりが稼動していればクライアントアプリケーションは
> 処理を行えますので、このエラーを通知する意味が薄れると思います。
> 
> もちろん、縮退運転モードに移行した時は、その事象を管理者に知らせる
> 必要がありますが、それはクライアントアプリケーションからではなく、
> 他の方法(例えばメールなど)でpgpoolから通知できるようになっていれば
> 十分ではないでしょうか。
> もしくは監視プログラムを別に用意するのでもいいと思います。
> 
> したがいまして、管理者への通知方法が別に設けられているならば、
> クライアントアプリケーションにエラーを通知せず、
> 黙ってセカンダリを切り放してもいいのでは…と考えています。

かなり大掛かりなな改造になるので(たとえば，pgpoolの他のプロセスにどう
やって切り放しを伝えるのかとか)すぐには対応できませんが，将来計画に組
み込んでおきたいと思います．
--
Tatsuo Ishii