[pgpool-general-jp: 1512] Re: pgpoolマスタとpostgresqlマスタ間のNW断時の挙動について

Tomohiro Hiramitsu hiramitsu.tomohiro ＠ lab.ntt.co.jp
2018年 3月 26日 (月) 19:23:05 JST 

石井さま

平光です
お世話になっております。

On 2018/03/23 18:03, Tatsuo Ishii wrote:
> 石井です。
> 
> 補足ですが、 https://www.sraoss.co.jp/event_seminar/material.php にあ
> る「 信頼性を向上させ、PostgreSQL 10 に対応した Pgpool-II 3.7 のご紹介」
> というスライドの、15ページ以降にwatchdogのquorumの解説があります。
ありがとうございます。本スライドは拝見させて頂いております。

> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
> 
>>> 平光です。
>>> お世話になっております。
>>>
>>> On 2018/03/22 16:00, Tatsuo Ishii wrote:
>>>> 石井です。
>>>>
>>>>> 平光です。
>>>>> お世話になっております。
>>>>>
>>>>> すみません、まだ 3.7.2-2では動作確認を出来ていないのですが、先に質問を
>>>>> させてください。
>>>>> 以下のリリース内容によって、pgpoolマスタ～postgresqlマスタ間のNWをダウ
>>>>> ンさせた際にread-onlyになってしまう件がどのように修正されるのかよく分
>>>>> かりませんでした。
>>>> 再考しましたが、結果として、3.7.2-2でも、同じ動作(read-only
>>>> transaction...)になると思います。混乱させて済みませんでした。
>>>> 今回何が起きているかというと、
>>>> 1) pgpoolマスタでは通常のfailoverは起きないが、node 0が隔離状態になる
>>>>      ので使用不可になる
>>>> 2) pgpool親プロセスはPostgreSQLのprimary nodeを探すが、当然見つからな
>>>>      いのでタイムアウト、primary nodeが-1に設定される
>>>> 3) 3.7.2では、この状況ではバグのためにprimary nodeにmaster node(この場
>>>>      合はnode 1)が設定される
>>>> クライアントから送られたwrite クエリは、3)により、スタンバイに送られて
>>>> (read-only transaction...)になる。
>>>> 3.7.2-2の場合は、3)は起きないが、2)により、仕方なくwriteクエリをスタン
>>>> バイに送って同じ結果になる。
>>>>
>>>>>> 今回のリリースでは、 3.7.2 のコミット
>>>>>> 9022ff842fb5dbbe06e2f2f4cf38fadf47b592da が
>>>>>> 取り消されました。今回のリリースによって、primary node が 0 以外の場合
>>>>>> でも更新
>>>>>> クエリを実行できるようになりました。
>>>>>
>>>>>
>>>>> 質問：
>>>>> =============
>>>>> １．
>>>>> バグであるのであれば、3.7.2-2ではpgpoolマスタ～postgresqlマスタ間のNW
>>>>> をダウンさせた際にどのような挙動をするのが仕様通りなのでしょうか。
>>>>> （pgpoolマスタが切り替わる、またはpostgresqlがフェイルオーバする.etc）
>>>> というわけで、期待される挙動は(read-only transaction...)です。
>>> ご回答ありがとうございます。
>>> 本障害発生時に3.7.2-2で期待される挙動は「read-only」ということで承知い
>>> たいしました。
>>>
>>> 本件は今後改修のご予定はありますでしょうか。それとも今回当方で試した環
>>> 境の構成、設定では対応できない障害パターンということでしょうか。
>>
>> 「改修」とは、どのような変更を期待されているのでしょうか？
>>
>> つまり、3つのPgpool-IIのうちひとつだけがバックエンドの障害を検知した場
>> 合、どう振る舞うべきとお考えですか？
分かり難くて申し訳ありません。整理させていただきますと

「3つのPgpool-IIのうちひとつだけがバックエンドの障害を検知した場合」というよりも、「正常にバックエンドのPostgreSQLへクエリを送信することができなくなったpgpoolノードはマスタを辞退して欲しい」というのが当方の認識です。 


紹介して頂いたスライド 
16pでは以下のように記述があり、プロセス異常などpgpool自身の障害発生時にはVIP(マスタ)を切り替えるものと理解しております。
・ 
Pgpool-II自身が単一障害点にならないように、バックアップのPgpool-IIを配置可能にする
・ Pgpool-IIに障害発生時には、別のPgpool-IIがVIPを引き継ぐ

ただ、今回のNW障害パターンではVIPの切り替えを行っていないようなので、そこが気になりました。（現状、プロセス異常などPgpool-II自身の障害以外は対象外ということでしょうか）

今回の障害パターンでは正常にPostgreSQLマスタにアクセスできない状態のpgpoolマスタを切り替えることができればread-onlyを回避できますが、現状では切り替えを実施しない、という点について「改修」の予定有無について質問させていただきました。 


>>
>>> また、繰り返しの質問で申し訳ありませんが、最初のメールで質問させて頂い
>>> た以下の質問もご確認をお願いできますでしょうか。
>>>
>>>>>>> 質問：
>>>>>>> ２. 以下のようにクォーラム機能をoffに設定した場合は、クォーラム機能が
>>>>>>> 実装される以前の3.6系と同じ挙動になるという理解で正しいでしょうか。
>>>>>>>      failover_when_quorum_exists = off
>>>>>>>      failover_require_consensus = off
>>>>>>>      allow_multiple_failover_requests_from_node = off
>>
>> 3.6系と同じ、というのはどのような振る舞いを期待されているのでしょうか？
クォーラム投票を実施せずにフェイルオーバを実行する
つまり、複数台のpgpoolの内 
1台でもマスタバックエンドの異常を検知すればpgpoolマスタ、スタンバイのいずれかがフェイルオーバを実行する。
という振る舞いになるのかと認識しております。

相違があればご指摘をお願いいたします。

以上です、よろしくお願いいたします。

>>
>>> 手元の環境では上記パラメータを全てoffにすると本障害発生時には3.6系と同
>>> 様の挙動(postgresqlフェイルオーバ)をすることは確認しているのですが、ド
>>> キュメントにはoffにした際の挙動について、特に明記されていないようでし
>>> たので念の為確認させて頂きたいです。
>>>
>>> 以上です、よろしくお願いいたします。
>>>
>>>>
>>>>> ２．
>>>>> 今回取り消されたコミットはALWAYS_MASTER がオンの場合に発生するバグの修
>>>>> 正かと思うのですが、当方の環境ではALWAYS_MASTERはデフォルトのオフ設定
>>>>> のままなので該当しません。
>>>>> （fail_over_on_backend_errorもデフォルトの「on」です。 ）
>>>>> 3.7.2-2でのコミット取り消しは上記のパラメータがデフォルトのままの環境
>>>>> にも影響するのでしょうか。
>>>> このバグに限って言えば、該当します。ALWAYS_MASTERがoffでも通るルートを
>>>> 修正しているので。
>>>>
>>>>> ３．
>>>>> 取り消されたコミットはバグフィックスのようですが、これは 3.7.2-2では該
>>>>> 当
>>>>> のバグは再発するようになっている、という認識で合っているでしょうか。
>>>> はい。元々修正したかった、ALWAYS_MASTERがonの時の挙動は直っていません。
>>>>
>>>>> =============
>>>>>
>>>>>
>>>>> なお、当方の認識では仮想IPを持っているpgpoolマスタがpostgresqlマスタに
>>>>> アクセスできない以上、pgpoolマスタかpostgresqlマスタのフェイルオーバを
>>>>> 実行しなけば仮想IPへのリクエストがread-onlyなってしまう事象は解消でき
>>>>> ないという認識です。
>>>> はい。
>>>>
>>>>> 3.7.2-2で修正されたバグはフェイルオーバの実行に関するものではないよう
>>>>> に見えましたので、私が質問させて頂いたのとは別のバグではないでしょうか？
>>>> はい、そうです。
>>>>
>>>>> 以上です、よろしくお願いいたします。
>>>>>
>>>>> On 2018/03/14 21:55, Tatsuo Ishii wrote:
>>>>>> 石井です。
>>>>>> Pgpool-II 3.7.2のバグである可能性があります。
>>>>>> Pgpool-II 3.7.2以外のバージョンを使用するか、git repositoryから3.7
>>>>>> stableのHEADを取得していただくか、本日リリースされたばかりのRPMをお試
>>>>>> しいただけますか？
>>>>>> 本日リリースされたRPMは、3.7 stable HEADと同等の内容です。
>>>>>> --
>>>>>> Tatsuo Ishii
>>>>>> SRA OSS, Inc. Japan
>>>>>> English: http://www.sraoss.co.jp/index_en.php
>>>>>> Japanese:http://www.sraoss.co.jp
>>>>>>
>>>>>>> 平光と申します。
>>>>>>> お世話になっております。
>>>>>>>
>>>>>>> お聞きしたい事があり、投稿させて頂きます。
>>>>>>>
>>>>>>> 3.7系で追加されたwatchdogクォーラム機能について質問させてください。
>>>>>>>
>>>>>>> 以下の構成の環境において、pgpoolマスタ～postgresqlマスタ間のNWをダウン
>>>>>>> させた状態で仮想IP(またはpgpoolマスタ)に対してSQLを実行するとサービス
>>>>>>> がread-onlyであると返ってきます。
>>>>>>>
>>>>>>> 以前の3.6系などクォーラム機能が追加される前はpgpoolがpostgresqlをフェ
>>>>>>> イルオーバさせていたのでサービスを継続できていましたが、3.7系では
>>>>>>> read-onlyになってしまっています。
>>>>>>>
>>>>>>> ・環境
>>>>>>> CentOS 7.4
>>>>>>> pgpool-II 3.7.2（ノード3台）
>>>>>>> postgresql 10.2（ノード2台）
>>>>>>>
>>>>>>> ・設定
>>>>>>> モード：ストリーミングレプリケーションモード
>>>>>>> watchdog：有効
>>>>>>> クォーラム機能：有効(デフォルト設定)
>>>>>>>      failover_when_quorum_exists = on
>>>>>>>      failover_require_consensus = on
>>>>>>>      allow_multiple_failover_requests_from_node = off
>>>>>>>
>>>>>>>
>>>>>>> NW断に利用したコマンドの例(pgpoolマスタで実行)
>>>>>>> ---
>>>>>>> # iptables -A OUTPUT -p all -s [pgpoolマスタ] -d [postgresqlマスタ] -j
>>>>>>> # DROP
>>>>>>> ---
>>>>>>>
>>>>>>> SQLエラーの例
>>>>>>> ---
>>>>>>> $ psql -h [仮想IP] -p 9999 -U postgres -d postgres -c "create table
>>>>>>> test (i int)"
>>>>>>> ERROR:  cannot execute CREATE TABLE in a read-only transaction
>>>>>>> ---
>>>>>>>
>>>>>>> pgpoolマスタでのshow pool_nodesの実行結果
>>>>>>> ---
>>>>>>>     node_id | hostname | port | status | lb_weight | role | select_cnt |
>>>>>>>     load_balance_node | replication_delay
>>>>>>> ---------+-------------+------+------------+-----------+---------+------------+-------------------+-------------------
>>>>>>>     0 | 192.168.1.1 | 5432 | quarantine | 0.500000 | standby | 0 | false |
>>>>>>>     0
>>>>>>>     1 | 192.168.1.2 | 5432 | up | 0.500000 | standby | 2 | true | 0
>>>>>>> (2 rows)
>>>>>>> ---
>>>>>>> ※192.168.1.1がpostgresqlマスタなので隔離されている
>>>>>>>
>>>>>>> また、以下を確認しました。
>>>>>>> ・各pgpoolノードに対してpcp_watchdog_infoを実行した結果から
>>>>>>> pgpoolマスタはNW断前後でノードが切り替わっていないことを確認。
>>>>>>>
>>>>>>> ・postgresqlサーバはフェイルオーバされていないことを確認。
>>>>>>>
>>>>>>>
>>>>>>> 上記の状況から、
>>>>>>> pgpoolマスタ～postgresqlマスタ間のNWをダウンさせた結果pgpoolマスタは
>>>>>>> postgresqlマスタを隔離したが、他の2台のpgpoolスタンバイノードは
>>>>>>> postgresqlマスタに正常にアクセスできるためクォーラム機能の投票の結果、
>>>>>>> フェイルオーバは実施されずpgpoolマスタも切り替わっていない。
>>>>>>> そのため、pgpoolマスタや仮想IPからはpostgresqlのスタンバイにアクセスし
>>>>>>> てしまうことでread-onlyになっていると推測しています。
>>>>>>>
>>>>>>> このような場合はpgpool側のマスタがスタンバイのいずれかに切り替わればサー
>>>>>>> ビスには影響が出ないと思いのですが、当方の環境では切り替わりませんでし
>>>>>>> た。
>>>>>>>
>>>>>>> 以下のページの「5.14.6. フェイルオーバの挙動の制御」の項目を見ると、上
>>>>>>> 記の挙動は想定通りにも見えますが、確認のため以下の２点を質問させてくだ
>>>>>>> さい。
>>>>>>> http://www.pgpool.net/docs/latest/ja/html/runtime-watchdog-config.html
>>>>>>>
>>>>>>>
>>>>>>> 質問：
>>>>>>> １．前述の環境構成時にpgpoolマスタ～postgresqlマスタ間のNWをダウンさせ
>>>>>>> ると仮想IP、pgpoolマスタからのアクセスがread-onlyになってしまうのは仕
>>>>>>> 様通りでしょうか。
>>>>>>>
>>>>>>> ２. 以下のようにクォーラム機能をoffに設定した場合は、クォーラム機能が
>>>>>>> 実装される以前の3.6系と同じ挙動になるという理解で正しいでしょうか。
>>>>>>>      failover_when_quorum_exists = off
>>>>>>>      failover_require_consensus = off
>>>>>>>      allow_multiple_failover_requests_from_node = off
>>>>>>>
>>>>>>>
>>>>>>> 以上です、よろしくお願いいたします。
>>>>>
>>>
>> _______________________________________________
>> pgpool-general-jp mailing list
>> pgpool-general-jp ＠ sraoss.jp
>> http://www.sraoss.jp/mailman/listinfo/pgpool-general-jp

pgpool-general-jp メーリングリストの案内