[pgpool-general-jp: 52] Re: pgpoolの縮退運転について

[Tatsuo Ishii]

石井です．

> 負荷分散は load_balance_mode = true によってのみ
> 機能が備わると思っていました。

はい，その理解で合っています．

> 実際 私も最初からreplication目的で利用しているもので
> master_slave_mode も loadbalance_mode も
> きちんと試せていませんので実証の裏付けのある事は言えないのですが...
> 
> > これなんですが、私の場合
> > 
> > Connection con;
> > PreparedStatement pstmt
> > Statement stmt
> > ResultSet rs
> > 
> > rs = stmt.executeQuery(sql);
> >  String dat = null;
> > while(rs.next) {
> >   dat = rs.getString(1);
> >   pstmt.clearParameters();
> >   pstmt.setString(1,s);
> >   pstmt.executeUpdate();
> > }
> > rs.close;
> > pstmt.close;
> > stmt.close;
> > con.close;
> > 
> > したりします。
> > 間違っているかもしれませんが、この時、pgpoolによるpoolの数が
> > ２つになるのではないかと考えました。

そういうことはないです．poolは，<ユーザ，データベース>のペア毎に作られ
るもので，同じユーザ，同じデータベースの接続を同じクライアントプロセス
からしている限りはpoolの数は1個でOKです．

> 今回、自分でアプリケーションを開発している訳ではないので、
> 残念ながらDB接続部分のソースは不明です。すみません。
> 
> > Tomcatをお使いという事なので、DBCPをご利用になられていると思います。
> > だとすると、Connection Poolは、DBCPが握っているので、接続取得と解放は
> > DBCP任せですよね。
> 
> 確かにその通りだと思います。
> 幸い、今回は接続に使うUser/DBの組み合わせが少ないもので、
> max_pool 部分はあまりパフォーマンス等にも関係ないかと思って
> 適当に設定してしまっているところもあります。
> 
> > 拝見しましたが、個別設定値は違いますが、縮退状態は、私の経験したもの
> > 同じです。
> > rsyncで、secondary と同期させた後でも、翌日にはこうなってしまうのであれば、
> > ヤバイですよね。
> 
> 原因が分からず、とても悩んでおります。
> 最近は、同時接続ユーザ数が多い場合に並列実行されるトランザクションの中で
> 瞬間的に発生したmaster/secondary間のデータ不一致状態にSELECTを実行してしまう
> ケースがあるのでは？とも考え始めました。
> (pgpoolの利用を前提に作られたアプリではないので、log_statementによるSQLの
>  記録を見る限りは、明示的なロックなどは入っていないように思われるので。)

その可能性はあります．

なので，load_balance_mode = off のときは，masterにだけSELECTを発行(現
在はsecondryにもSELECTを投げている)するようにしたらどうかな，と思って
います．ただ，副作用のあるSELECTが来る可能性があるので，コメントかスイッ
チで動作を選べるようにした方がよいかもしれません．
--
Tatsuo Ishii
SRA OSS, Inc. Japan