<div dir="ltr">Hi all,<div><br></div><div>I have the following setup: 2 identical virtual machines with pgpool 3.5.4 and postgresql 9.5.4 and CentOS 7.</div><div><br></div><div>The first one, let's call it A, has master postgresql and primary pgpool.</div><div>The second one, let's call it B, has slave postgresql (in hot standby) and secondary pgpool.</div><div>I think this setup is pretty common.</div><div><br></div><div>The two pgpool are configured with a delegate ip, watchdog, health check on both backends and a failover command.</div><div>The setup seems to work correctly at first.<br></div><div><br></div><div>The problem is that, to assess failover, we try bringing down the network on vm A.</div><div>This should cause the following:</div><div><ul><li>pgpool on B should react becoming primary pgpool and adding delegate ip to its ethernet device</li><li>pgpool, after the configured number of attempts to connect to master database on A should promote postgresql on B using the configured failover_command.</li></ul><div>First point was successful, second one was not.</div></div><div>After attempting to connect to postgresql on A appears a message that notify that backend on A is declared down, but no failover command was issued and SHOW pool_nodes shows postgresql on A as online.</div><div>Moreover attempts to connect to postgresql on A continue forever.</div><div><br></div><div>Note that restarting pgpool fixes all problems. </div><div>It declares itself primary since it cannot reach its counterpart on A, brings up delegate ip and after configured number of attempts promotes postgresql on B as new master.</div><div><br></div><div>So this definitely seems a bug, and indeed a tichet was already be opened for it.</div><div><a href="http://www.pgpool.net/mantisbt/view.php?id=227&history=1">http://www.pgpool.net/mantisbt/view.php?id=227&history=1</a><br></div><div><br></div><div>My question is the following: our setup and in particular having two nodes with one pgpool and one postgresql is ideal or is it advisable to arrange services in more nodes or differently?</div><div><br></div><div>IMHO the probability that one node goes down entirely or becomes unreachable is bigger than a failure of the sole postgresql service.</div><div>Thus, due to this bug, we risk to have no high avaiability at all and to be left with a read-only database.</div><div>Obviously our client is not very happy with that since we have a more complex setup with little advantages.</div><div><br></div><div>Is there any news on bug resolution timing?</div><div><br></div><div>Is there any workaround that I can use to mitigate the impact?</div><div>For instance, I may setup pgpools in order to have primary on B.</div><div>Getting rid of pgpool promotion probably does trigger postgresql failover.</div><div><br></div><div>What is your opinion?</div><div><br></div><div>Best regards,</div><div><br></div><div>Gabriele Monfardini</div><div><br></div><div>-----<br></div><div><div><div class="gmail_signature"><div dir="ltr"><div>Gabriele Monfardini<br>LdP Progetti GIS</div><div>tel: 0577.531049<br>email: <a href="mailto:monfardini@ldpgis.it" target="_blank">monfardini@ldpgis.it</a></div></div></div></div>
</div></div>