[pgpool-general-jp: 1739] Re: pgpool2と接続したレプリケーション構成でverify_backend_node_statusから出力されるプライマリからスタンバイへの接続エラーメッセージ出力を抑止したい

2024年 10月 1日 (火) 17:54:45 JST

> -----Original Message-----
> From: Tatsuo Ishii <ishii ＠ postgresql.org>
> Sent: Tuesday, October 1, 2024 5:47 PM
> To: pgpool-general-jp ＠ pgpool.net
> Cc: Tomofuji, Masao/友藤 正雄 <tomofu ＠ fujitsu.com>
> Subject: Re: [pgpool-general-jp: 1736] Re: pgpool2と接続したレプリケーション構成でverify_backend_node_statusから
> 出力されるプライマリからスタンバイへの接続エラーメッセージ出力を抑止したい
> 
> >> 以下の構成にした場合に発生する事象について、対処方法をご相談させてください。
> >>
> >> [事象]
> >> * プライマリとスタンバイ間で、ストリーミングレプリケーションが正しく
> >>   接続されているにもかかわらず、以下のメッセージが出力されます。
> >>    LOG:  verify_backend_node_status: primary XXX does not connect to standby XXX
> >>    LOG:  verify_backend_node_status: primary XXX owns only XXX
> >> standbys out of XXX
> >>
> >> [事象が発生する構成]
> >> * pgpoolサーバーが1台、バックエンドノードが2台(プライマリ1台、
> >>   スタンバイ1台)の構成で、バックエンドノードへの接続とレプリケーションの
> >>   接続で利用するネットワークが異なる場合に発生します。
> >>   具体的には、以下のようにIPアドレスを設定した場合に発生します。
> >>   [pgpool Server: pgpool.conf]
> >>   * backend_hostname0 = '${APP_HOST_DB#0}' # DB#0はプライマリ
> >>   * backend_hostname1 = '${APP_HOST_DB#1}' # DB#1はスタンバイ
> >>
> >>   [DB#1: postgresql.conf]
> >>   * primary_conninfo = '... host=${REP_HOST_DB#0} ...'   # backend_hostname0 と異なるホスト名
> >>
> >> [調査して判明したこと]
> >> * 過去のメーリスでは、backend_hostnameとprimary_conninfoで
> >>   異なるホスト名を指定した場合には、上記のエラーが発生するとコメントがありました。
> >>   * [pgpool-hackers: 3943] Re: verify_backend_node_status does not recognise that the primary is connected to
> standbys
> >>     https://www.pgpool.net/pipermail/pgpool-hackers/2021-July/003944.html
> >>
> =========================================================================
> >>       I think the reason you are seeing these errors is that pgpool tries to
> >>       compare backend_hostname2 (dbod-ag-pg03.ch) and backend_port2 (6600)
> >>       with host and port (dbod-hac-c02.ch, 6600) in primary_conninfo. In
> >>       this case port matches but hostname does not match and Pgpool-II
> >>       regards that the standbys do not connect to the primary node,.
> >>
> >> =====================================================================
> >> ====
> >>
> >> * verify_backend_node_status()のソースコードを確認したところ、
> >>   確かにbackend_hostnameとprimary_conninfoのhostの文字列比較を
> >>   行っていることを確認しました。
> >>   また、このエラーが出力される場合には、デタッチ対象のノードである
> >>   フラグを更新できないため、detach_false_primary パラメータの処理が
> >>   動作しない影響があるように見えました。
> >>
> >> [相談事項]
> >> (1) verify_backend_node_status()では、バックエンドノードへの接続と
> >>     レプリケーション接続でネットワークが異なる場合に対応していないという
> >>     認識で合ってますでしょうか。
> >
> > はい、ご認識の通りです。
> >
> >> (2) 上記(1)の認識が正しい場合、本事象のメッセージを抑止するために、
> >>     detach_false_primaryパラメータを無効化するしかないでしょうか。
> >
> > はい、そうです。
> >
> >> [気になっている点]
> >> ・今回のエラーが出力される場合には、デタッチ対象のノードである
> >>   フラグを更新できないため、detach_false_primary パラメータの処理が
> >>   動作しない影響がある、という認識は正しいでしょうか。
> >
> > primary/standbyそれぞれ1台の構成では、detach_false_primaryが検出できる
> > 異常状態は、standbyをオペミスなどで間違って昇格してしまい、primaryが2
> > 台、standbyが0台の状況だけです。この場合は、2台のprimaryのうちどちらが
> > 正しいprimaryなのかはpgpoolは判定できないため、node 1のprimaryを切り離
> > すことになります(決め打ちでnode番号のわかりprimaryを残します)。この一
> > 連の動作において、primaryとstandbyの接続性の検証は行われないので、今回
> > のエラーは影響しません。
> 
> ところで念の為に教えていただきたいのですが、primary PostgreSQLの
> listen_addressesには、以下のように複数のIPが設定されている状態でしょうか？
> 
> listen_addresses = '${APP_HOST_DB#0},${REP_HOST_DB#0}'

ご指摘ありがとうございます。
確認を取れ次第、返信させて頂きます。

> --
> Tatsuo Ishii
> SRA OSS K.K.
> English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp