<div dir="ltr">Hi Hackers,<div><br></div><div>This is the proposal to make the failover of backend PostgreSQL <span id="gmail-5293d208-bdc7-4c35-b135-f036b83ea693" class="gmail-GINGER_SOFTWARE_mark">nodes</span> quorum aware to make it more robust and fault tolerant.<br><div><br></div><div>Currently Pgpool-II proceeds to <span class="gmail-GINGER_SOFTWARE_mark"><span id="gmail-bce935fb-8f00-45d7-8204-6e01c636b449" class="gmail-GINGER_SOFTWARE_mark"><span id="gmail-6ea96736-41b6-4b77-a693-180e399bf6db" class="gmail-GINGER_SOFTWARE_mark">failover</span></span></span> the <span id="gmail-035954d5-dad5-4d60-a4a9-9821dc350d54" class="gmail-GINGER_SOFTWARE_mark"><span id="gmail-0425ba51-e8cd-4cca-a0cc-112a05c0682f" class="gmail-GINGER_SOFTWARE_mark">backend</span></span> node as soon as the health check detects the failure or in case of an error occurred on the <span id="gmail-1905d5d3-f1ce-45b6-8cfd-a997af8f4a4f" class="gmail-GINGER_SOFTWARE_mark"><span id="gmail-be210301-0618-4c03-baa9-76b7b6fb69b7" class="gmail-GINGER_SOFTWARE_mark">backend</span></span> connection <span id="gmail-967d89b8-e132-4f9c-a954-31851a5af561" class="gmail-GINGER_SOFTWARE_mark">(</span>when fail_over_on_<span id="gmail-c7af583e-b6d3-4f04-94ab-cee0f6bdcabf" class="gmail-GINGER_SOFTWARE_mark">backend</span>_error is set). This is good enough for the standalone Pgpool-II server.</div><div><br></div><div>But consider the scenario where we have more than one Pgpool-II (Say Pgpool-A<span class="gmail-GINGER_SOFTWARE_mark gmail-GINGER_SOFTWARE_mark">, </span>Pgpool-B and Pgpool-C) in the cluster connected through watchdog and each Pgpool-II node is configured with two PostgreSQL <span id="gmail-2fe08256-3b85-414c-87ac-5bc58b938ed7" class="gmail-GINGER_SOFTWARE_mark"><span id="gmail-5bb67908-d12e-46d6-ba5f-168fe6e637cf" class="gmail-GINGER_SOFTWARE_mark"><span id="gmail-4b7f716d-ceb3-4b9e-8a4e-db5473f15631" class="gmail-GINGER_SOFTWARE_mark">backends</span></span></span> (B1 and B2). </div><div><br></div><div>Now if due to some network glitch or an issue, Pgpool-A fails or loses its network connection with <span id="gmail-4fcdc19c-1403-4770-9a37-827dd3541930" class="gmail-GINGER_SOFTWARE_mark">backend</span> B1, The Pgpool-A will detect the failure and detach (failover) the B1 backend and also pass this information to the other Pgpool-II nodes (Pgpool-II B and Pgpool-II C), Although the Backend B1 was perfectly healthy and it was also reachable from Pgpool-B and Pgpool-C nodes, But still because of a network glitch between Pgpool-A and Backend B1, it will get detached from the cluster and the worst part is, if the B1 was a master PostgreSQL (in master-standby configuration), the Pgpool-II <span id="gmail-21930999-1a3b-4939-847b-04023e071033" class="gmail-GINGER_SOFTWARE_mark">failover</span> would also promote the B2 PostgreSQL node as a new master, hense making the way for split-brain and/or data corruptions.</div><div><br></div><div>So my proposal is that when the Watchdog is configured in Pgpool-II the <span id="gmail-dc7c58b9-6f87-4df9-ae55-3c48488dc1a4" class="gmail-GINGER_SOFTWARE_mark">backend</span> health check of Pgpool-II should consult with other attached Pgpool-II nodes over the watchdog to decide if the Backend node is actually failed or if it is just a localized glitch/false alarm. And the failover on the node should only be performed, when the majority of cluster members agrees on the failure of nodes.</div><div><br></div><div>This quorum aware architecture of failover will prevents the false failovers and split-brain
scenarios in the Backend nodes. </div><div><br></div><div>What are your thoughts and suggestions on this?</div><div><br></div><div>Thanks</div><div>Best regards</div><div>Muhammad Usama</div><div><br></div></div></div>