[pgpool-general-jp: 1384] Re: ドキュメントバグ？ Streaming Replicationでのクエリ振り分けについて
Kazuki Uehara
uehara.kazuki ＠ lab.ntt.co.jp
2015年 8月 5日 (水) 11:58:24 JST
SRA OSS石井様
上原です。
お世話になっております。
>> ■本題
>> [pgpool-general-jp: 1380] で追加で確認させていただきたい内容は
>> ・SHOW
>> がロードバランシング対象か否かについてです。
>>
>> マニュアルではロードバランシングの対象となっていますが、こちらで
>> 確認した限りではロードバランシングの対象外という認識です。
>> ご確認いただけないでしょうか。
>
> はい、実装上はそうなっています。これもマニュアルを修正します。
>
> SHOWで表示される値はプライマリとスタンバイで異なっている可能性があります。
> 今のところpgpool-IIでは、プライマリの値だけを表示させています。
本件について、理解しました。
ご確認いただきありがとうございます。
以上です。
よろしくお願いします。
(2015/08/05 11:50), Tatsuo Ishii wrote:
> 上原様
>
> お世話になっています。SRA OSS石井です。
>
>> SRA OSS石井様
>>
>> 上原です。
>> お世話になっております。
>>
>>
>> 誤解させてしまい申し訳ありません。
>>
>>>> 試しにDECLAREをロードバランシングさせてみたのですが、以下のようなエラー
>>>> が出力されました。
>>
>> こちらは、「試しにソースをいじって」DECLAREをロードバランシングの対象にして
>> みましたときの話ですので、pgpool-II 3.4.2の仕様ではDECLAREはノード1
>> （スタンバイ）に行くことはありません。
>>
>> 誤解を招くような書き方になってしまい、失礼しました。
>
> こちらこそ早とちりで失礼しました。
>
>> ■本題
>> [pgpool-general-jp: 1380] で追加で確認させていただきたい内容は
>> ・SHOW
>> がロードバランシング対象か否かについてです。
>>
>> マニュアルではロードバランシングの対象となっていますが、こちらで
>> 確認した限りではロードバランシングの対象外という認識です。
>> ご確認いただけないでしょうか。
>
> はい、実装上はそうなっています。これもマニュアルを修正します。
>
> SHOWで表示される値はプライマリとスタンバイで異なっている可能性があります。
> 今のところpgpool-IIでは、プライマリの値だけを表示させています。
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
>
>> 以上です。
>> よろしくお願いします。
>>
>>
>> (2015/08/05 10:17), Tatsuo Ishii wrote:
>>> 上原様
>>>
>>> お世話になっています。SRA OSS石井です。
>>>
>>> ノード0がプライマリだと仮定して、そもそもDECLAREがノード1に負荷分散され
>>> ているのがおかしいですね。まずはここから調べてみます。
>>> --
>>> Tatsuo Ishii
>>> SRA OSS, Inc. Japan
>>> English: http://www.sraoss.co.jp/index_en.php
>>> Japanese:http://www.sraoss.co.jp
>>>
>>>> SRA OSS石井様
>>>>
>>>> 上原です。
>>>> お世話になっております。
>>>>
>>>>
>>>> ご確認いただきありがとうございます。
>>>> マニュアルの修正、よろしくお願いします。
>>>>
>>>> 五月雨になってしまい申し訳ないのですが、「SHOW」もDECLAREと同様で
>>>> PRIMARYに振られているようです。（pgpool-II 3.4.2）
>>>> マニュアルではロードバランシングの対象と記載されているので、DECLARE
>>>> と合わせて修正いただけると幸いです。
>>>>
>>>>
>>>> 以下、確認ログです。
>>>>
>>>> 念のため、src/context/pool_query_context.cに以下のデバッグログを入れて
>>>> 確認しております。
>>>>
>>>> ----------------
>>>> /*
>>>> * Other statements are sent to primary
>>>> */
>>>> ereport(LOG,(errmsg("[debug_k] Other statements")));←★追加
>>>> return POOL_PRIMARY;
>>>> }
>>>> --------------
>>>>
>>>>
>>>> $ psql -h 192.168.1.3 -p 9999 -U user1 testdb -c "show SERVER_VERSION"
>>>>
>>>> pgpool.log
>>>> ---------
>>>> 2015-08-04 19:30:29: pid 15678: LOG: [debug_k] Other statements
>>>> 2015-08-04 19:30:29: pid 15678: LOG: DB node id: 0 backend pid: 13625 statement: show SERVER_VERSION
>>>> ---------
>>>>
>>>>
>>>>
>>>>> ところで2.2.6のコミットログ(ed5a6338cc83fc00ffdac89025eb7a59d6024d4b)を
>>>>> 見直してみると、"Fix is_select_query() not to allow cursor statements.
>>>>> Close() should not allowed since hold cursor + update may cause data
>>>>> inconsistency." とあるのですが、正直自分がコミットしたにも関わらず自分
>>>>> でもなぜこのように考えたのか覚えていません:-)
>>>>>
>>>>> うーん、思い出せるかどうか頑張ってみます。
>>>>
>>>>
>>>> ＜以下、余談です。＞
>>>>
>>>> 試しにDECLAREをロードバランシングさせてみたのですが、以下のようなエラー
>>>> が出力されました。
>>>>
>>>> 実施概要：JDBC使用（AutoCommit OFF）
>>>> DECLARE後にFETCHを何回か実行する
>>>>
>>>> pgpool.log
>>>> ---------------
>>>> 2015-08-04 19:55:53: pid 16692: LOG: DB node id: 0 backend pid: 13731 statement: Execute: BEGIN
>>>> 2015-08-04 19:55:53: pid 16692: LOG: DB node id: 1 backend pid: 24379 statement: Execute: BEGIN
>>>> 2015-08-04 19:55:53: pid 16692: LOG: DB node id: 1 backend pid: 24379 statement: Parse: DECLARE cur2 CURSOR WITH HOLD FOR SELECT * FROM bar2
>>>> 2015-08-04 19:55:53: pid 16692: LOG: DB node id: 1 backend pid: 24379 statement: B message
>>>> 2015-08-04 19:55:53: pid 16692: LOG: DB node id: 1 backend pid: 24379 statement: D message
>>>> 2015-08-04 19:55:53: pid 16692: LOG: DB node id: 1 backend pid: 24379 statement: Execute: DECLARE cur2 CURSOR WITH HOLD FOR SELECT * FROM bar2
>>>> 2015-08-04 19:55:53: pid 16692: LOG: [debug_k] Other statements
>>>> 2015-08-04 19:55:53: pid 16692: LOG: DB node id: 0 backend pid: 13731 statement: Parse: FETCH FIRST FROM cur2
>>>> 2015-08-04 19:55:53: pid 16692: LOG: DB node id: 0 backend pid: 13731 statement: B message
>>>> 2015-08-04 19:55:53: pid 16692: LOG: DB node id: 0 backend pid: 13731 statement: D message
>>>> 2015-08-04 19:55:53: pid 16692: LOG: DB node id: 0 backend pid: 13731 statement: Execute: FETCH FIRST FROM cur2
>>>> 2015-08-04 19:55:53: pid 16692: LOG: pool_send_and_wait: Error or notice message from backend: : DB node id: 0 backend pid: 13731 statement: "FETCH FIRST FROM cur2" message: "cursor "cur2" does not exist"
>>>> 2015-08-04 19:55:53: pid 16692: LOG: DB node id: 1 backend pid: 24379 statement: ABORT
>>>> 2015-08-04 19:55:53: pid 16692: LOG: DB node id: 0 backend pid: 13731 statement: ABORT
>>>> ----------------
>>>>
>>>> DECLAREをnode:1で実行したあとにFETCHがnode:0に向いていたのでエラーに
>>>> なっていました。ですので、もしカーソル系を分散させたいなら全nodeに
>>>> DECLAREをしたりするのでしょうか？
>>>> # もともと外された理由を理解できていないので、トンチンカンなことを
>>>> 言っていたらすみません。
>>>>
>>>>
>>>> 以上です。
>>>> よろしくお願いします。
>>>>
>>>>
>>>> (2015/08/04 17:48), Tatsuo Ishii wrote:
>>>>> 上原様
>>>>>
>>>>> お世話になっています。SRA OSS石井です。
>>>>>
>>>>>> 上原と申します。
>>>>>> お世話になっております。
>>>>>>
>>>>>> pgpool-II 3.4.2 でロードバランシングの対象となるSQLについて確認して
>>>>>> いたところ、マニュアルの記述に誤りと思われる箇所がありました。
>>>>>> ご確認いただけないでしょうか。
>>>>>>
>>>>>> ---------
>>>>>> ○Streaming Replicationでのクエリ振り分け
>>>>>> ・Primary/Standbyどちらにも送ることのできる問い合わせ。
>>>>>> - DECLARE, FETCH, CLOSE
>>>>>> ---------
>>>>>> （pgpool-II マニュアルから一部抜粋）
>>>>>>
>>>>>> 上記のように記載されているのですが、確認したところカーソル系のSQLは
>>>>>> ロードバランシングの対象とはなっておらず、全てPrimaryに向けられて
>>>>>> いるようです。
>>>>>>
>>>>>> src/context/pool_query_context.c
>>>>>> send_to_where()
>>>>>> -------
>>>>>> 1213 /*
>>>>>> 1214 * Other statements are sent to primary
>>>>>> 1215 */
>>>>>> 1216 return POOL_PRIMARY;
>>>>>> -------
>>>>>> ここで、DeclareCursorStmtはPOOL_PRIMARYに落ちているかと思います。
>>>>>>
>>>>>>
>>>>>> # 調べた後で気づきましたが、
>>>>>> 2.2.6 のリリースノートにDECLAREをロードバランシングの対象から外した
>>>>>> という記述がありましたので、おそらくその時期から残っていたのかと思います。
>>>>>
>>>>> 仰るとおりで、マニュアルの記述が更新されていないようです。修正いたします。
>>>>> ご指摘ありがとうございました。
>>>>>
>>>>> ところで2.2.6のコミットログ(ed5a6338cc83fc00ffdac89025eb7a59d6024d4b)を
>>>>> 見直してみると、"Fix is_select_query() not to allow cursor statements.
>>>>> Close() should not allowed since hold cursor + update may cause data
>>>>> inconsistency." とあるのですが、正直自分がコミットしたにも関わらず自分
>>>>> でもなぜこのように考えたのか覚えていません:-)
>>>>>
>>>>> うーん、思い出せるかどうか頑張ってみます。
>>>>> --
>>>>> Tatsuo Ishii
>>>>> SRA OSS, Inc. Japan
>>>>> English: http://www.sraoss.co.jp/index_en.php
>>>>> Japanese:http://www.sraoss.co.jp
>>>>
>>>>
>>>> --
>>>> 上原 一樹 (Kazuki Uehara)
>>>> Mail : uehara.kazuki ＠ lab.ntt.co.jp
>>>> Phone: 03-5860-5115
>>>>
>>>> _______________________________________________
>>>> pgpool-general-jp mailing list
>>>> pgpool-general-jp ＠ sraoss.jp
>>>> http://www.sraoss.jp/mailman/listinfo/pgpool-general-jp
>>
>>
>> --
>> 上原 一樹 (Kazuki Uehara)
>> Mail : uehara.kazuki ＠ lab.ntt.co.jp
>> Phone: 03-5860-5115
>>
>> _______________________________________________
>> pgpool-general-jp mailing list
>> pgpool-general-jp ＠ sraoss.jp
>> http://www.sraoss.jp/mailman/listinfo/pgpool-general-jp
--
上原 一樹 (Kazuki Uehara)
Mail : uehara.kazuki ＠ lab.ntt.co.jp
Phone: 03-5860-5115
pgpool-general-jp メーリングリストの案内