[pgpool-hackers: 3308] Re: duplicate failover request over allow_multiple_failover_requests_from_node=off
harukat at sraoss.co.jp
Tue Apr 16 18:42:40 JST 2019
Hello Usama, and Pgpool Hackers
Thanks for your answer.
I tried your patch adjusting it for V3.7.x.
In the scenario where the enabled health check find the connection failure
and its recover, it works fine. But in the scenario where the health check
is disabled and frontend requests find them, quarantine status is continued
in the pgpool.
I understand that this patch aims to recover from the quarantine status
by health check. I confirmed it works so well. I think it can be a help for
our customer at certain cases.
However, there is a problem Ishii-san pointed out, witch continues emitting
health check failure messages while its cause remains.
A pgpool node who notices that it cannot get consensus or it's a minority
will go down soon; I prefer this simple behavior rather than quarantining.
Does any one tell me the reason why this design wasn't adopted?
with best regards,
On Mon, 15 Apr 2019 19:14:54 +0500
Muhammad Usama <m.usama at gmail.com> wrote:
> Thanks for the patch, But your patch effectively disables the node
> quarantine, which does't seems a right way.
> Since the backend node that was quarantined because of absence of quorum
> and/or consensus is already un-reachable
> form the Pgpool-II node, and we don't want to select it as load-balance
> node ( in case the node was secondary) or consider it
> as available when it is not by not marking it as quarantine.
> In my opinion the right way to tackle the issue is by keep setting the
> quarantine state as it is done currently but
> also keep the health check working on quarantine nodes. So that as soon as
> the connectivity to the
> quarantined node resumes, it becomes the part of cluster automatically.
> Can you please try out the attached patch, to see if the solution works for
> the situation?
> The patch is generated against current master branch.
More information about the pgpool-hackers