[pgpool-general: 6791] Re: VIP and quorum

Muhammad Usama m.usama at gmail.com
Wed Dec 4 23:11:13 JST 2019


Hi

Thanks for pointing that out. This is an infect the documentation mistake.
The failover_require_consensus has nothing to do with VIP and it only
configures the behaviour of backend node failover.
The acquisition  VIP by master(active) Pgpool-II only depends upon the
existence of a quorum.
I will update the documentation to rectify this mistake

Thanks
Best regards
Muhammad Usama


On Tue, Nov 19, 2019 at 7:08 AM Rafael Thofehrn Castro <rafaelthca at gmail.com>
wrote:

> Hi all,
>
> I am testing pgpool 4.1.0 and ended up in something I found inconsistent.
> This is the description of the delegate_IP parameter in 4.1:
>
> > Specifies the virtual IP address (VIP) of Pgpool-II that is connected
> from client servers (application servers etc.). When a Pgpool-II is
> switched from standby to active, the Pgpool-II takes over this VIP. If
> failover_require_consensus
> <https://www.pgpool.net/docs/latest/en/html/runtime-watchdog-config.html#GUC-FAILOVER-REQUIRE-CONSENSUS> is
> on (the default), VIP will not be brought up in case the quorum does not
> exist. Default is ''(empty): which means virtual IP will never be brought
> up.
>
> The part that explains about failover_require_consensus says that if this
> parameter is enabled then VIP will not be claimed if quorum does NOT exist.
> I assume that if I DISABLE this parameter then VIP will be claimed even
> there is no quorum.
>
> However, when testing with a 3 nodes cluster and
> failover_require_consensus disabled, when I shutdown two nodes the third
> one doesn't claim the VIP. This is what the log states:
>
> > LOG:  I am the cluster leader node but we do not have enough nodes in
> cluster
> > DETAIL:  waiting for the quorum to start escalation process
>
> In fact, I checked the source code and found no relationship between failover_require_consensus
> and escalation.
>
> I'm not complaining about the behavior, just that it seems inconsistent
> with what the doc states. Or perhaps I misunderstood it.
>
> Regards,
>
> Rafael Castro.
>
> _______________________________________________
> pgpool-general mailing list
> pgpool-general at pgpool.net
> http://www.pgpool.net/mailman/listinfo/pgpool-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20191204/8445f97c/attachment.html>


More information about the pgpool-general mailing list