<div dir="ltr">Hi all,<div><br></div><div>I have a setup with two pgpools in HA and two backends in streaming replication.</div><div>The problem is that, due to unattended upgrade, master has been restarted and master pgpool has correctly started failover.</div><div><br></div><div>We would like to prevent this, playing with health_check parameters, in order for pgpool to cope with short master outage without performing failover.</div><div><br></div><div>I&#39;ve found an old blog post of Tatsuo Ishii, <a href="http://pgsqlpgpool.blogspot.it/2013/09/health-check-parameters.html">http://pgsqlpgpool.blogspot.it/2013/09/health-check-parameters.html</a>, in which the following statement is made:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="color:rgb(85,85,68);font-family:tahoma,&#39;Trebuchet MS&#39;,lucida,helvetica,sans-serif;font-size:13px;line-height:18.2px">Please note that &quot;health_check_max_retries * (health_check_timeout+health_check_retry_delay)&quot; should be smaller than health_check_period.</span></blockquote><div><br></div><div>Looking at the code however it seems to me that things are a little different (probably I&#39;m wrong).</div><div><ol><li>in main loop health check for backends is performed (do_health_check), starting from 0 to number_of_backends</li><li>suppose that i-th backend health check fails because of timeout. The process is interrupted by the timer.</li><li>if (current_try &lt;= health_check_max_retries) =&gt; sleep health_check_retry_delay<br></li><li>we&#39;re back in main loop, the health check restart from i, the backend for which health_check failed</li><li>suppose that health_check fails again and again</li><li>when (current_try &gt; health_check_max_retries) =&gt; set backend down<br></li><li>we&#39;re back in main loop, the health check restart from i, the backend for which health_check failed, but now its state is DOWN so we continue to next backend</li><li>in main loop when do_health_check exits, all backend are down or all backend currently not down are healthy</li><li>then we sleep health_check_period in main loop before starting again the check from the beginning.</li></ol></div><div><br></div><div>If I understand it correctly, health_check_period is slept unconditionally at the end of the check so it is not needed to set it as high as per the formula in the blog.</div><div><br></div><div>Moreover if there are many backends and many failures last backend may be checked again after a long time, in the worst case after about</div><div><br></div><div><font face="monospace, monospace">(number_of_backends-1) * health_check_max_retries * (health_check_timeout+health_check_retry_delay) + health_check_period</font></div><div><br></div><div>Suppose that I choose that is acceptable that master may goes down for at max 120 seconds before failover.</div><div><br></div><div>Since I have only two backends, I should probably set </div><div><br></div><div><font face="monospace, monospace">health_check_max_retries * (health_check_timeout+health_check_retry_delay) + health_check_period</font></div><div><br></div><div> to about 120s.</div><div><br></div><div>Let&#39;s say</div><div><ul><li>health_check_period = 10<br></li><li>health_check_max_retries = 11<br></li><li>health_check_timeout =10<br></li><li>health_check_retry_delay = 1<br></li></ul></div><div>If at time 0 master goes down and health_check is started, after 11 tries that takes 10+1 seconds each, failover is triggered at time 121</div><div><br></div><div>In case all health checks returns OK in negligible time, that should happens almost always, health_check_period assures that no checks are done for next 10 seconds.</div><div><br></div><div>Can you please confirm my findings or correct me?</div><div><br></div><div>Best regards,</div><div><br></div><div>Gabriele Monfardini</div><div><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>-----<br>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>