<div dir="ltr"><div>Hi Luca,</div><div><br></div><div>I'm aware our setup is somewhat atypical. The reason for this setup is that we ship our application as a virtual appliance that's supposed to be a single deployment. Running in a cluster means deploying the same appliance 3 times. Things like a VIP work very nicely in most situations, but for us its really not an option as the cluster setup is supposed to be an internal detail from the perspective of the customer.</div><div><br></div><div>We are thinking about implementing a safeguard that monitors the local pgpool watchdog and shuts down the database, pgpool and the application in case it reports having lost the quorum. However, this requires additional monitoring, polling and it would be much more reliably if pgpool could initiate this itself.</div><div><br></div><div>Best regards,</div><div>Emond</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 5, 2021 at 4:53 PM Luca Maranzano <<a href="mailto:liuk001@gmail.com">liuk001@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:small"><div style="font-size:small">Hi,</div><div style="font-size:small">IMHO
 the application should not run on the same server of the database, but 
in any case the application should connect to the VIP managed by the 
pgpool cluster not to the local pgpool. <br></div><div style="font-size:small">The
 case is anyway interesting because there is no way for the Primary 
Postgres to kill itself (a la STONITH way) in case of network partition.</div><div style="font-size:small"><br></div><div style="font-size:small">Regards,</div><div style="font-size:small">Luca</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 5, 2021 at 4:26 PM Emond Papegaaij <<a href="mailto:emond.papegaaij@gmail.com" target="_blank">emond.papegaaij@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>While running various cluster failover and recovery tests, we came across an issue that I would like to discuss here. These tests were performed in a setup with 3 nodes (for simplicity called node 1, 2 and 3). Each node runs a database, pgpool and an application instance. The application connects to the local pgpool, which in turn connects to all 3 databases, sending all queries to the one that is currently primary. Suppose node 1 runs the primary database. When this node is disconnected from the other 2 nodes via a simulated network failure, the other nodes establish consensus to perform a failover and either node 2 or 3 is selected for the new primary. However, on node 1, the database remains writable and the application and pgpool running. If the application on this node is still reachable from the load balancer, it will continue to serve requests, resulting in a split brain and ultimately database corruption.</div><div><br></div><div>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?</div><div><br></div><div>Best regards,</div><div>Emond Papegaaij</div></div>
_______________________________________________<br>
pgpool-general mailing list<br>
<a href="mailto:pgpool-general@pgpool.net" target="_blank">pgpool-general@pgpool.net</a><br>
<a href="http://www.pgpool.net/mailman/listinfo/pgpool-general" rel="noreferrer" target="_blank">http://www.pgpool.net/mailman/listinfo/pgpool-general</a><br>
</blockquote></div>
</blockquote></div></div>