[pgpool-general: 7863] Re: Rejecting database mutations without a quorum

[Emond Papegaaij]

>
> > For many of our customers this is unwanted behavior. They would rather
> see
> > the service become unavailable than continue to operate in a split
> brain. I
> > went through the available options on pgpool, but could not find an
> option
> > that would help me here. I'm looking for a way to prevent pgpool from
> > accessing its backends with its watchdog is not part of a quorum. Is this
> > currently possible in pgpool? If not, is it worth considering adding a
> > feature for this?
>
> One of the difficulties with this kind of approach is, how to decide
> that the primary should be killed in a reliable way.
>
> Suppose we have:
>
> node 1: pgpool/watchdog 1, primary PostgreSQL
> node 2: pgpool/watchdog 2, standby PostgreSQL
> node 3: pgpool/watchdog 3, standby PostgreSQL
>
> The scenario:
>
> 1) Watchdog 1 lost communication to watchdog 2 and watchdog 3. So
>    watchdog 1 lost quorum.
>
> 2) However communication between pgpool 1/2 and the primary is still
> healthy.
>
> 3) Watchdog 1 decides to kill the primary and the primary goes down.
>
> 4) pgpool 1/2 have to promote one of the standbys to create new primary.


Yes, this always is the issue with communication within a cluster, or more
specifically the loss of communication. That's why I wanted to discuss this
here. What happens to a VIP in your scenario if watchdog 1 started with the
VIP assigned? Will watchdog 1 drop the VIP when it losses the quorum? Is
the pgpool 1 still supposed to receive queries when it can no longer be
sure it is sending them to the correct database?

In our setup, what I would ideally see is that I can configure pgpool to
not send writes (or completely disconnect all its backends) when the
instance is not part of a quorum. Also, it would be really great if I can
configure a command when the watchdog status changes. That would allow me
to implement custom behavior myself.

Best regards,
Emond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20211108/712a2f71/attachment.htm>