[pgpool-general: 4972] health_check_* options

[Krzysztof Mościcki]

Hello.

I red this article about health_check_* options:
http://pgsqlpgpool.blogspot.com/2013/09/health-check-parameters.html and
i liitle confised, because author of article was wrote, that:

Please note that "health_check_max_retries *
(health_check_timeout+health_check_retry_delay)" should be smaller than
health_check_period.

In can't find about it in official pgpool documentation. It is really
required?


And second question. I'm testing those options on Google Cloud servers,
with the following options:

health_check_period = 60
health_check_timeout = 10
health_check_max_retries = 3
health_check_retry_delay = 7

(health_check_period=60 because of above article). I use also repmgr
with connect_timeout=10s, so whole time switch is about 2 minutes, i.e.
(time: mm:ss):

39:03 - master node goes down
39:51 - pgpool see, that is problem to connect
40:08 - failed mode, retry 1
40:25 - retry 2 (time between retry 1 and retry 2: 10 sec for connect
timeout and 7 second for delay for next retry)
40:42 - retry 3
40:52 - pgpool mark node as a down, and run failover script (10s timeout
after retry 3)
41:02 - promoting slave as a master through repmgr (repmgr checking,
that old master really not working, so next 10s, because of timeout)


I use health_check_retry_delay = 7 for situation, when i.e. postgresql
instance not works but server works, so any attepmt to connect are
immediately rejected, so timeout is very short, and time for failover is
also very short.

So I'm thinking about shorter time health_check_period and also connect
timeout. I set 10s, but what do you think, what value will be good in
cloud services (AWS, Google Cloud etc). Load on postgres servers is
low/medium.

Best regards,
Kris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20160908/506f14be/attachment.html>