<div dir="ltr"><div>Hi All</div><div><br></div><div>I am looking into pgpool-II failover with watchdog issues. <br><ul><li>Issue 234: pgpool fails to run failover script if the sever running primary pgpool node and postgresql server dies<br></li><li>Issue 227: failover not performed by standby node<br></li></ul></div><div><br></div><div>Currently I am little stuck on deciding the best possible solution to the above problems, So I am sharing the simplified scenario, problems and possible solutions with the wider audience for the thoughts and suggestions</div><div><br></div><div>Scenario</div><div>=========</div><div>Consider two <span id="e475fb0d-f64d-4c0b-8168-84fa549bfdf4" class="gmail-GINGER_SOFTWARE_mark gmail-GINGER_SOFTWARE_mark gmail-GINGER_SOFTWARE_mark gmail-GINGER_SOFTWARE_mark gmail-GINGER_SOFTWARE_mark"><span id="gmail-25de81fc-ff79-47ca-b10e-1744e9c2982e" class="gmail-GINGER_SOFTWARE_mark">machines each</span></span> with a PostgreSQL and pgpool-II installation as given below:<br></div><div><br></div><div>Machine (M1)</div><div>================</div><div>PostgreSQL (PG1)</div><div><span id="gmail-d17e7cef-01e1-4566-8d69-b92d3a7aa4c2" class="gmail-GINGER_SOFTWARE_mark">pgPool</span>-II (PGP1)</div><div><br></div><div><div>Machine (M2)</div><div>================</div><div>PostgreSQL (PG2)</div><div><span id="gmail-62eea71d-677f-4ffc-9dab-bde8d140fca2" class="gmail-GINGER_SOFTWARE_mark">pgPool</span>-II (PGP2)</div></div><div><br></div><div><br></div><div>So the cluster may be configured as:</div><div><div>================================</div><div>PGP1 [backend_0 = PG1(local), backend_1 = PG2(remote)]</div><div>PGP2 [backend_0 = PG1(remote), backend_1 = PG2(local)]</div></div><div><br></div><div><br></div><div>Each pgpool-II has two <span id="gmail-55fb0f7b-268c-47f5-bb1e-25d88fcba1ea" class="gmail-GINGER_SOFTWARE_mark"><span id="gmail-49c2f161-6958-4897-b8f8-ecfdf05e104d" class="gmail-GINGER_SOFTWARE_mark">backend</span></span> nodes configured, one on the <span id="gmail-a65723c8-c0e6-4dc7-b539-2ecb5bd02495" class="gmail-GINGER_SOFTWARE_mark">local machine</span> and <span id="gmail-b33a3f0b-c2f8-4f62-8f68-50fb6545569a" class="gmail-GINGER_SOFTWARE_mark">another</span> on the remote second machine. Also, both the pgpool-II nodes are connected through watchdog.</div><div><br></div><div>When this cluster boot up and link is fine, one of the pgpool-II node will become a master watchdog node and the other will join in as a standby watchdog while the status of both <span id="gmail-23d7f61e-99c6-4546-a30e-70efac28efc4" class="gmail-GINGER_SOFTWARE_mark">backend</span> PG nodes on each pgpool-II is [UP].<br></div><div><br></div><div>Scenario:</div><div>================</div><div>Now consider if we disconnect the network link between M1 and M2:</div><div><ul><li>Watchdog communication between the PGP1 and PGP2 will be disconnected, but still each pgpool-II node will NOT consider the other node as lost till the watchdog <span id="gmail-3472b926-317b-4a7d-a143-eec7b1273c0a" class="gmail-GINGER_SOFTWARE_mark"><span id="gmail-b9635f1d-ab75-4e52-bfe8-700e294b3e06" class="gmail-GINGER_SOFTWARE_mark">lifecheck</span></span> process (depending on the configuration) will mark the other node as dead. </li><li>At the same instance in time, PGP1 will lose the link with backend_1 (PG2) and PGP2 will lose the link with backend_0 (PG1) and both pgpool-II nodes will start the failover of the failed <span id="eb68cd37-6e33-4f89-924c-0029e22bb52e" class="gmail-GINGER_SOFTWARE_mark gmail-GINGER_SOFTWARE_mark gmail-GINGER_SOFTWARE_mark gmail-GINGER_SOFTWARE_mark gmail-GINGER_SOFTWARE_mark"><span id="gmail-333127cd-a63c-40da-8439-d1ea475e88ee" class="gmail-GINGER_SOFTWARE_mark">backend</span></span> PostgreSQL node. </li></ul>Because of the configuration and events, both pgpool-II are performing the failover on a different PG <span id="gmail-16e24530-f267-4af1-8edd-89db23f5737e" class="gmail-GINGER_SOFTWARE_mark"><span id="gmail-3059cc61-fc4d-4d1c-90cc-7c892fae5d95" class="gmail-GINGER_SOFTWARE_mark">backend</span></span> node. One <span id="gmail-a8c758d8-f3a5-444a-ab3d-82f269943f20" class="gmail-GINGER_SOFTWARE_mark"><span id="gmail-bef5e14d-7ae2-4bdb-a712-de0bf2e72007" class="gmail-GINGER_SOFTWARE_mark">pgpool</span></span> is degenerating PG1 while the other is degenerating PG2 at the same time and also the communication link at the moment does not exist between pgpool-II nodes.<br></div><div><br></div><div>Problems</div><div>=========</div><div>1 -- Since the communication link is broken between pgpool-II nodes so neither pgpool-II node will not be able to communicate the degenerate request to other pgpool-II node. </div><div><br></div><div>2 -- As all the locks and interlockings are handled by the master watchdog node, and the standby watchdog pgpool-II node will not be able to communicate with the master watchdog pgpool-II node, So standby pgpool-II node will not be able to acquire or coordinate the locking. </div><div><br></div><div>3 -- If both pgpool-II nodes get done with respective <span id="gmail-61c4861c-6b40-43c4-9a47-a5030b980500" class="gmail-GINGER_SOFTWARE_mark">backend</span> node failover and communication link is restored. Both pgpool-II will be connected to different <span id="gmail-b039b81c-c1fe-45f1-92ee-573f8b2ed6e1" class="gmail-GINGER_SOFTWARE_mark">backend</span> node and both <span id="gmail-8e951118-ed21-4a92-b856-a19fdf78735b" class="gmail-GINGER_SOFTWARE_mark">backend</span> nodes might have become the master PostgreSQL node at that time.</div><div><br></div><div><br></div><div>Possible Solutions</div><div>==============</div><div><br></div><div>For Problem #1</div><div>============</div><div>As the communication link is broken between pgpool-II nodes, Sending the degenerate request to other pgpool-II node will fail with time-out. So when the <span id="gmail-4cb6560e-fb23-4099-8f2c-5b6b22bfba15" class="gmail-GINGER_SOFTWARE_mark">time-out</span> <span id="gmail-237bb9dd-1a99-4c96-ace2-7a64d65549b8" class="gmail-GINGER_SOFTWARE_mark">occurs, we</span> have two options.</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"></blockquote><ol><li>Consider it as a temporary failure and enqueue the command until the watchdog cluster elects the new master node or become the single node cluster and process the command at that time.<br></li><li>Consider it as a success and proceed with the node failover even when the time-out on watchdog failover command occurs.<br></li></ol><div><div>For Problem #2</div><div>============</div></div><div>As the node will be isolated, especially the standby pgpool-II node so it will not be able to coordinate/acquire/release the locks, and all lock requests will get fail with time-out. Again, we have multiple options here</div><div><br></div><div><ol><li>Time-out on locking command can be considered as the lock-acquire failure, and consequently neither pgpool-II node will execute the user provided failover command.<br></li><li>Consider time-out on locking command as the lock acquired and as a result, both pgpool-II nodes will execute the user provided failover commands.</li><li>Finally, we can consider it as a temporary failure and enqueue the first lock command issued to the watchdog and keep it queued till the watchdog elects the new master or become the single node cluster. And till that time pgpool-II will keep waiting for the lock command to be completed.</li></ol></div><div>For Problem #3</div><div>=============</div><div>If the communication is restored and both pgpool-II has a different <span id="gmail-bb271462-cbaa-4414-bd97-3ab232488e79" class="gmail-GINGER_SOFTWARE_mark">backend</span> status from each other, both pgpool-II nodes should shutdown itself and let the user restart it again after verifying the data consistency among PostgreSQL servers.</div><div><br></div><div><br></div><div>Please give your valuable feedback and suggestions to reach the best possible solution for the above.</div><div><br></div><div><br></div><div>Thanks in anticipation</div><div>Best regards</div><div>Muhammad Usama</div><div><br></div><div><br></div><div><br></div><div><br></div><div>       </div></div>