[pgpool-hackers: 33] Re: [pgpool-general: 131] Healthcheck timeout not always respected

[Stevo Slavić]

Hello Tatsuo,

2012/2/28 Tatsuo Ishii <ishii at postgresql.org>

> > I was thinking in that direction before (adding backend flag, or another
> > configuration option to have pgpool failover only on health check).
>
> No, I was proposing a flag which prevents pgpool from automatic
> failover in case the admin shutdown detected, because you don't want
> to be failovered by admin shutdown.
>

Yes, that would handle detected admin shutdown, but one should be able to
turn off failover on connection to backend failure too, to give health
check complete control over failover:
fail_over_on_backend_error = off
fail_over_on_backend_admin_shutdown = off
fail_over_on_backend_connect_failure = off

+ configure health check
+ configure appropriate backend flag to ALLOW_TO_FAILOVER


> > But, I
> > came to conclusion that there is absolutely no purpose for healthcheck if
> > it's not sole process controlling failover. If you have an example to
> prove
> > me wrong, please share:
> > 1) example where one would want to enable healthcheck but not allow it to
> > cause failover at all
>
> A is a streaming replication primary and B, C ... are standbys. A is
> protected by a HA technology (heartbeat, pacemaker or some such). Upon
> failure of A, D which is the cold standby of A will come up.  don't
> want A failovers while wants B, C failovers. So user sets health check
> on and DISALLOW_TO_FAILOVER for A.
>

If I understood correctly, in this case user doesn't actually need pgpool
health check for backend A, but needs it for backends B and C - maybe
health check or backend configuration should be extended so one can
configure for which backend(s) pgpool health check is actually needed. By
default backend could be configured that it supports health check (so if
health check is configured that backend state would be checked by
healthcheck, otherwise it wouldn't), and one would have to turn off health
check support for given backend explicitly (so even if health check is
configured, it would skip checking such backend).
With this health check would not waste time or connection resources by
skipping checking backends that shouldn't be checked.

So backend_healthcheck with two values {supports} and {skip}


>
> Here is another one.
>
> A is a streaming replication primary and B, C ... are standbys. The
> system is used for OLAP type purpose. The OLAP application keeps on
> connection to standbys. Upon failure of A, it doesn't need to failover
> A because the application happily keeps on using standbys. So user
> sets health check on and DISALLOW_TO_FAILOVER for A. Probably fix and
> replacing A would be postpned to night time.
>

Again, same solution - extend health check / backend configuration to
support excluding backend from health check.


>
> > 2) example where one would want to enable healthcheck and have pgpool
> > failover immediately on anything other then health check (max retries)
> > failure
>
> The network is very fast and stable. There are many servers and they
> are pretty busy. User don't like overhead of healthcheck, however user
> want to detect the failure of server as soon as possibole. So he
> disables health check.


This case is not affected by proposed change/patch - if you check code
again you'll see that it affects only users which have backend set to
DISALLOW_TO_FAILOVER and at the same time have health check configured. For
ones that have health check disabled (health_check_period = 0), that big if
will never be entered.

Kind regards,
Stevo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20120228/192787eb/attachment.html>