[pgpool-general-jp: 1357] pgpool3.3.5 ロードバランスについて

[近藤]

近藤と申します。pgpoolを利用させて頂いております。

ずっと、postgresql 8系 と pgpool 2.2.6 を使用しておりましたが、postgreSQL を
9.3系へ更新に合わせて、pgpool 3.3.5 の動作テストを行っております。その中で、疑問点が２点ありまして、確認をお願いしたく思います。

動作条件

レプリケーションモード
pgpool サーバ  centos 5.11
postgreSQLサーバ centos 6.6  postgreSQL 9.3.6



１．ロードバランス条件について

マニュアルには、以下のように「条件をすべて満たした場合にロードバランス」とあります。

>load_balance_mode = true を設定した場合、以下の条件のすべてを満たした>時に
SELECTなどの問い合わせがロードバランスされます。
>◾PostgreSQLのバージョンが7.4以降である
>◾問い合わせが明示的なトランクザションブロックの内側にない(つまり、>BEGINを発行していない)

しかし、内部処理を見ますと pool_query_context.c においては以下のようになっています。

                        else if (TSTATE(backend, MASTER_NODE_ID) == 'I' ||
                                         (!pool_is_writing_transaction() &&
                                          !pool_is_failed_transaction() &&
                                          pool_get_transaction_isolation()
!= POOL_SERIALIZABLE))
                       {
                                /* load balance */
                                pool_set_node_to_be_sent(query_context,

session_context->load_balance_node_id);
                        }



動作チェックを行うと、psqlで通常時は TSTATE(backend, MASTER_NODE_ID) == 'I' となっており、beginを
発行した直後のselect では、 'I' 以外となっています。定義上も、下記のようになっています。

        char tstate;            /* Transaction state (V3 only) 'I' if idle
                                                 * (not in a transaction
block); 'T' if in a
                                                 * transaction block; or
'E' if in a failed
                                                 * tra


つまり、トランザクションの外部 or 他の条件を満たせばロードバランスされておりまして、内部であってもロードバランスされてしまいます。 || でなく
&& であるべきかと思いますが、どうでしょうか？



２．レプリケーションモード時の挙動仕様について

レプリケーションモードの場合、update や
deleteは全てのノードに送られます。読むだけのselectは高速化のためにロードバランス可能として頂いていると認識しています。また、トランザクション内部の場合などは、更新副作用のある場合を考慮して、ロードバランスされないと受け止めています。

そのため、ロードバランスされない場合、レプリケーションモードを利用している場合、update や delete
と同様に、全てのノードに送られる仕様であると助かります。現在は、マスターノードのみに送られます。

これは、replicate_select を true にすると、ひとまず両方に送られますが、この対応ではselect
のロードバランスが全くされないため、パフォーマンスが大きく下がってしまいます。また、更新やinsertが多数ある状態ですと、タイミングによって、ノード間の不一致がごく一時的に発生している状態の単純なselect
がエラーとなってしまう恐れが高いと思っています。


以上２点、よろしくお願いいたします。
-------------- next part --------------
HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...
URL: <http://www.sraoss.jp/pipermail/pgpool-general-jp/attachments/20150305/a5c1aa52/attachment-0001.html>