[pgsql-jp: 41658] Re: pgpoolの縮退運転について

[岩田]

石井様、岩田です。

お返事ありがとうございます。

>> 石井様に助言を頂いて、改めてマニュアルを確認してみたのですが、pgpoolの設
>> 定のうち、縮退に関わるものとしては 「replication_stop_on_mismatch、
>> failover_if_affected_tuples_mismatch」が あるんですね。
>> "replication_stop_on_mismatch"は、パケットの種類を見て縮
>> 退、"failover_if_affected_tuples_mismatch"は結果行数を見て縮退するとあり
>> ますが、今回の場合 は"failover_if_affected_tuples_mismatch"のチェックに
>> 引っかかって切り離されたと考えられるということ でしょうか？としても、
>> ABORTさせるクエリをpgpoolが発行しているので、
>> failover_if_affected_tuples_mismatch=falseの動きをしているように見えま
>> す。
> はい、そうです。

なるほど。2.3には"failover_if_affected_tuples_mismatch"の設定がないので
すが、やはり内部では falseの動きとなっているのですね。

>> であれば、切り離しされないと思いますが、そこはreplication_stop_on_mismatch=trueが効いているのでしょうか？
> はい、これも推察のとおりだと思います。

でしたら、今回のケースでは、「replication_stop_on_mismatch=false」であっ
たならば、ABORTはするが、 切り離しはされなかったと考えれますか？


> おそらく切り離し自体は、UPDATE結果行数の相違という現象とはまた別の、
> replication_stop_on_mismatchに引っかかるような現象によって起こったのだ
> と思います。pgpool-IIのログがないので、それが何だったのかはわかりません。

ABORTと切り離しが二段階で評価されているのならば合点いきます。
しかし、結果行数が違ってABORTした上で切り離しまでする運用を良しとするか
は検討の必要がありますね。。それよりも、普通に運用していると きに、
UPDATE文の実行に失敗するケースはなんだろうと考えてしまいます。

結局、切り離しの原因は結果行数が異なることに起因してそうなので、まずは詳
細を得るためにpgpool-IIのログを取ることが肝要ですね。

お願いいたします。