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

Emond Papegaaij emond.papegaaij at gmail.com
Mon Nov 8 19:56:27 JST 2021

> > 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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20211108/712a2f71/attachment.htm>

More information about the pgpool-general mailing list