[pgpool-general-jp: 1264] Re: pgpoolから発行されるSQLの挙動について

[Tatsuo Ishii]

> 石井様
> 
> お世話になります、貞永です。
> 
> 調査頂きありがとうございます。
> 無害ということで安心しました。
> 
> 発生条件で確認なのですが、最初の問い合わせにも書きましたが、
> ・DBがストリーミングレプリケーションの２台構成（非同期）
> ・pgpoolでロードバランシング、コネクションプール、マスタスレーブモードをon
> 
> ・当初スレーブであったDBをマスタに昇格し
> ・当初マスタであったDBを新マスタを元にスレーブとした
> この環境にて、新スレーブのDBにて今回と同じ様にpgpoolが発行するSQLがpg_stat_activityでstateがactiveのまま残ってしまう。（新マスター側では残らない）
> 
> という状況が発生しています。（検証環境でも確認しています）
> これは発生条件２について逆も起こりうると考えてよろしいのでしょうか？

起こりません。

> そもそもpgpoolが発行するSQLがスレーブに行くこと自体は問題ではありませんでしょうか？

問題があります。pgpool-IIは、新しいマスタをマスタとして認識していないの
ではないでしょうか？show pool_nodesコマンドでpgpool-IIの認識状態を確認
すると共に、PostgreSQLのスレーブが本当にstandbyとして動いているかどうか
をご確認ください。

もしPostgreSQLが正しくstandbyになっているにも関わらず、pgpool-IIがそう
認識していない場合は、以下のバグに該当する可能性があります。

http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=13d8da7f97a31e29e38972fceaf5b173a7ac430d

パッチをお試しください。
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

> よろしくお願いします。
> 
> 
> 2014年1月31日 18:44 Tatsuo Ishii <ishii ＠ sraoss.co.jp>:
> 
>> 石井です。
>>
>> ソースコードを調べた結果、結論としては「無害」です。
>>
>> この現象が発生する条件ですは、
>>
>> 1) 拡張問い合わせモード(-M extendedあり)
>>
>> 2) 同じセッションの中で、pgpool-IIが内部で発行するクエリがマスタに送ら
>>    れ、ユーザクエリは負荷分散によってマスタ以外に送られた
>>
>> のANDです。PostgreSQLは、pg_stat_activityで表示されるクエリがidleになる
>> 条件として、クライアント(この場合はpgool-II)から"sync"というメッセージ
>> が送られてくることなのです。ところが、syncを送ってしまうと、PostgreSQL
>> が勝手に無名ポータル(executorのハンドルのようなもの)を削除してしまい、
>> ユーザクエリが無名ポータルで実行中の場合に、後続のクエリが実行できなく
>> なってしまいます(しょうがないのでpgpool-IIは、syncの代わりに"flush"とい
>> うメッセージを送るようにしています)。
>>
>> # PostgreSQLが、コマンドが正常終了したら、ステータスをactiveからidleに
>> # してくれれば良いのですが...
>>
>> PostgreSQLの処理が現状のままである限り、今のところpgpool-II側では回避方
>> 法がないため、無視していただくようにお願いします。
>>
>> 更にご興味のある方は、src/backend/postmaster/postmaster.c、
>> src/backend/tcop/postgres.cの3915行あたり(行数は現時点のmaster branch)
>> をご覧ください。
>> --
>> Tatsuo Ishii
>> SRA OSS, Inc. Japan
>> English: http://www.sraoss.co.jp/index_en.php
>> Japanese: http://www.sraoss.co.jp
>>
>> > 石井様
>> >
>> > お世話になります、貞永です。
>> >
>> > -M extendedなし場合は発生しません。
>> > pg_stat_activityではstateがidleになっています。
>> > 実際に負荷がけした時のログを添付します。
>> >
>> > よろしくお願いします。
>> >
>> >
>> >
>> > 2014年1月29日 17:57 Tatsuo Ishii <ishii ＠ sraoss.co.jp>:
>> >
>> >> 石井です。
>> >>
>> >> この現象は、-M extended なしでも発生しますか？
>> >> --
>> >> Tatsuo Ishii
>> >> SRA OSS, Inc. Japan
>> >> English: http://www.sraoss.co.jp/index_en.php
>> >> Japanese: http://www.sraoss.co.jp
>> >>
>> >> > お世話になります、貞永です。
>> >> >
>> >> > 昨年末から問い合わせさせていただているpgpoolから発行される
>> >> > SELECT count(*) FROM pg_catalog.pg_class AS c WHERE c.oid =
>> >> > pgpool_regclass('ユーザーテーブル') AND c.relpersistence = 'u'
>> >> > についてですが、いろいろ検証している中で気になる挙動が有りましたので、ご報告させていただきます。
>> >> >
>> >> > 構成は、
>> >> > pgpool-ii：: 3.3.1、マスタースレーブモード、ロードバランスモード、コネクションプールモードを使用
>> >> > PostgreSQL：9.3.0、ストリーミングレプリケーションでマスタ１台、スレーブ１台
>> >> > それぞれ別サーバーで、OSはCentOS6.4(64bit)
>> >> >
>> >> > pgbenchを使った負荷がけ(-S、-M extended)を行って確認しました。
>> >> >
>> >> > DB1号機(マスター)側で負荷がけ中のpg_stat_activityを見ると
>> >> > SELECT count(*) FROM pg_catalog.pg_class AS c WHERE c.oid =
>> >> > pgpool_regclass('pgbench_accounts') AND c.relpersistence = 'u'
>> >> > がずーっとactiveのままで残っていました。
>> >> > pgbenchが終了すると上記にSQLもきれいに消えています。
>> >> >
>> >> > psqlで\dxでpgpool_regclassが入っていることも確認しています。
>> >> >
>> >> > また、1号機をマスターからスレーブに切替を行った場合でも、スレーブの１号機にのみ同様の現象が発生します。
>> >> >
>> >> >
>> >>
>> 以前、石井様からはこのSQLがアプリケーションのSQL発行前に実行され、それが終わらないとアプリのSQLが実行されないとおしえていただいたのですが、今回の現象において、これが起因してアプリケーションが遅くなっているようには見えませんでした。
>> >> >
>> もともと、実際にシステム上に常に上記のSQLがLogTransactionとなってしまっているため、別途検証環境で検証を行い再現ができました。
>> >> > 参考までに、検証環境での負荷がけ時のログを添付します。
>> >> >
>> >> > この挙動は、実害がないよう見えていますが、不具合ではないでしょうか？
>> >> > もし不具合であれば解消の検討もしていただけるとありがたいです。
>> >> >
>> >> > 調査、確認の程よろしくお願いします。
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >>
>> >
>> >
>> >
>> > --