<div dir="ltr"><div dir="ltr">On Mon, Nov 8, 2021 at 12:52 PM Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>> One of the difficulties with this kind of approach is, how to decide<br>
>> that the primary should be killed in a reliable way.<br>
>><br>
>> Suppose we have:<br>
>><br>
>> node 1: pgpool/watchdog 1, primary PostgreSQL<br>
>> node 2: pgpool/watchdog 2, standby PostgreSQL<br>
>> node 3: pgpool/watchdog 3, standby PostgreSQL<br>
>><br>
>> The scenario:<br>
>><br>
>> 1) Watchdog 1 lost communication to watchdog 2 and watchdog 3. So<br>
>>    watchdog 1 lost quorum.<br>
>><br>
>> 2) However communication between pgpool 1/2 and the primary is still<br>
>> healthy.<br>
>><br>
>> 3) Watchdog 1 decides to kill the primary and the primary goes down.<br>
>><br>
>> 4) pgpool 1/2 have to promote one of the standbys to create new primary.<br>
> <br>
> <br>
> Yes, this always is the issue with communication within a cluster, or more<br>
> specifically the loss of communication. That's why I wanted to discuss this<br>
> here. What happens to a VIP in your scenario if watchdog 1 started with the<br>
> VIP assigned? Will watchdog 1 drop the VIP when it losses the quorum?<br>
<br>
Yes.<br>
<br>
> Is<br>
> the pgpool 1 still supposed to receive queries when it can no longer be<br>
> sure it is sending them to the correct database?<br>
<br>
I am not sure what you mean here. It's user's responsibility to send<br>
queries to a pgpool which does not have quorum but Pgpool-II assumes<br>
that clients sends queries to VIP.<br></blockquote><div><br></div><div>What I meant here was, if a Pgpool that is not part of a quorum (and therefore should no longer hold the VIP), receives a query, should it process this query? In a 'normal' setup, it should not get the query, but if it does, what should it do with it? It could be that the VIP was not correctly reassigned, or a system connecting to Pgpool is configured incorrectly. I would say, it would be nice if Pgpool could be configured to reject any queries when it cannot be sure it is sending them to the correct database.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> In our setup, what I would ideally see is that I can configure pgpool to<br>
> not send writes (or completely disconnect all its backends) when the<br>
> instance is not part of a quorum. Also, it would be really great if I can<br>
> configure a command when the watchdog status changes. That would allow me<br>
> to implement custom behavior myself.<br>
<br>
Maybe you misunderstand Pgpool-II's architecture. In a Pgpool-II<br>
cluster, Pgpool-II and PostgreSQL processes are logically separated<br>
objects. Whether Pgpool-II and PostgreSQL processes are running on a<br>
separate host or not is irrevant to the functionality of the cluster.<br></blockquote><div><br></div><div>Yes, I'm aware of this. In our situation, we currently have a database and a Pgpool on every node, but that's purely our setup. It is very likely we will allow this to be changed in the future, with support for nodes that only run the database or special arbiter nodes that only run Pgpool. However, we cannot use a VIP as all nodes are linked together using a wireguard network on which we cannot have VIPs.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On the other hand I understand your motivation. Allowing to have a<br>
command which is called when watchdog quorum status changes might be a<br>
good idea.<br></blockquote><div><br></div><div>This would be of tremendous help for us, because it will allow us to plug in our own behavior driven directly by Pgpool. This would eliminate the need to poll Pgpool, which I fear will be too unreliable. If a poll fails due to a short glitch, I do not want to bring down a node right away. Also, if the process doing the polling fails for whatever reason, the whole setup will be at risk of corruption.</div><div><br></div><div>Best regards,</div><div>Emond</div><div> </div></div></div>