[pgpool-general-jp: 1266] Re: pgpoolから発行されるSQLの挙動について
Tatsuo Ishii
ishii ＠ sraoss.co.jp
2014年 2月 7日 (金) 11:52:40 JST
石井です。
そうですか。たぶん実害はないと思います。時間ができたときに調べておきます。
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
> 石井様
>
> お世話になります、貞永です。
>
> 回答頂いた内容で検証してみましたが、結果は変化ありませんでした。
>
> 元スレーブをマスターに切替、元マスターをスレーブにした場合、show pool_nodesでは、
> node_id | hostname | port | status | lb_weight | role
> ---------+------------+------+--------+-----------+---------
> 0 | 10.0.0.102 | 5432 | 2 | 0.500000 | standby
> 1 | 10.0.0.104 | 5432 | 2 | 0.500000 | primary
> として正常に認識されています。
> この状況でpgbenchの-S -M extendを行ってみると、pgpoolにパッチをあてる前では
> SELECT count(*) FROM pg_catalog.pg_class AS c WHERE c.oid =
> pgpool_regclass('pgbench_accounts') AND c.relpersistence = 'u'
> はスレーブ側にしか発行されていません。
>
> pgpoolにパッチを当て(main.c)、コンパイルしました。
> 元々のpgpoolはhttp://pgpool.net/mediawiki/index.php/Downloads
> からダウンロードしたRPMで、/usr/bin/pgpool(サイズ1151234バイト)
> ソースにパッチを当ててコンパイルしたものは/usr/local/bin/pgpool(サイズ2871863バイト)
> とディレクトリがわかれていたので、pgpoolの起動を切り替えて検証しました結果も、上記のSQLはスレーブ側でしか発行されていませんでした。
> パッチをあてたpgpoolでの実行ログを添付します。
>
> 前回の頂いた回答からすると、上記のSQLは本来マスター側で実行されるべきもので、それなのに、スレーブ側で実行されることが問題であるという認識であっていますでしょうか？
> もし、今回の様な場合は実害としてはなにか起こりうるものなのでしょうか？
>
> 上記の現象について、調査、対応方法の検討をよろしくお願いします。
>
>
>
> 2014年2月5日 10:51 Tatsuo Ishii <ishii ＠ sraoss.co.jp>:
>
>> > 石井様
>> >
>> > お世話になります、貞永です。
>> >
>> > 調査頂きありがとうございます。
>> > 無害ということで安心しました。
>> >
>> > 発生条件で確認なのですが、最初の問い合わせにも書きましたが、
>> > ・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となってしまっているため、別途検証環境で検証を行い再現ができました。
>> >> >> > 参考までに、検証環境での負荷がけ時のログを添付します。
>> >> >> >
>> >> >> > この挙動は、実害がないよう見えていますが、不具合ではないでしょうか？
>> >> >> > もし不具合であれば解消の検討もしていただけるとありがたいです。
>> >> >> >
>> >> >> > 調査、確認の程よろしくお願いします。
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>>
>
>
>
> --
> ┌───────────────────────┐
> 株式会社アイティフォー
> 事業本部 技術企画部 貞永 佳市
> Mail: ksadanaga ＠ itfor.co.jp
> Tel: 03-5275-7903 (内線: 61466)
> └───────────────────────┘
pgpool-general-jp メーリングリストの案内