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

[Tatsuo Ishii]

>> 以下の構成にした場合に発生する事象について、対処方法をご相談させてください。
>> 
>> [事象]
>> * プライマリとスタンバイ間で、ストリーミングレプリケーションが正しく
>>   接続されているにもかかわらず、以下のメッセージが出力されます。
>>    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