[pgpool-general: 3548] Re: health_check_period formula

[Tatsuo Ishii]

>> > health_check_max_retries *
>> (health_check_timeout+health_check_retry_delay)"
>> > < health_check_period.

The formula was wrong. Sorry.

Actually you can set any value to health_check_period what ever values
are set to health_check_timeout, health_check_max_retries and
health_check_retry_delay.

So the settings:
>> > health_check_period = 30
>> > health_check_timeout = 5
>> > health_check_max_retries = 20
>> > health_check_retry_delay = 2

perfectly makes sense.

Here is what health checks works:

1) start a health check cycle

2) connect(2) to PostgreSQL backend

3) if #2 failed or did not respond within health_check_timeout seconds
   and health_check_max_retry reaches, the health check fails

4) if #2 success go to #7

5) sleep health_check_retry_delay seconds and count down
   health_check_max_retry counter

6) go to #2

7) sleep health_check_period seconds.

8) go to #1

As you can see, health_check_period does not affect a health check
cycle (#2 to #6).

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp


> Thanks for the reply,
> 
> I'm on 3.3.1, I'll upgrade.
> 
> I'm not hitting an error, just checking those settings are OK even though
> the post I linked mentions a formula which I don't satisfy.
> 
> Cheers,
> James Sewell
> 
> On Monday, 16 March 2015, Tatsuo Ishii <ishii at postgresql.org> wrote:
> 
>> You don't mention what pgpool-II version you use nor the actual error
>> message but It seems you are bitten by the bug fixed in 3.3.4 (I assume
>> you use 3.3.x):
>>
>>
>> http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=d0443ccc27ae1bbbc0715427072ffe67f632fd20
>>
>> If so, please upgrade your pgpool-II installation (the laresr version
>> is 3.3.5, BTW).
>>
>> Best regards,
>> --
>> Tatsuo Ishii
>> SRA OSS, Inc. Japan
>> English: http://www.sraoss.co.jp/index_en.php
>> Japanese:http://www.sraoss.co.jp
>>
>> > Hey all,
>> >
>> > This page
>> > http://pgsqlpgpool.blogspot.com.au/2013/09/health-check-parameters.html
>> > suggests that this formula must be observed (I can't see this in the doco
>> > though?):
>> >
>> > health_check_max_retries *
>> (health_check_timeout+health_check_retry_delay)"
>> > < health_check_period.
>> >
>> > I am running on AWS and the network is pretty terrible sometimes,
>> although
>> > the problem isn't timeouts. When it fails connections fail straight
>> away. I
>> > was hoping to use these settings:
>> >
>> > health_check_period = 30
>> > health_check_timeout = 5
>> > health_check_max_retries = 20
>> > health_check_retry_delay = 2
>> >
>> > But according the the above formula I would need a health_check_period of
>> > 20*(5+2) = 140.
>> >
>> > I would rather avoid this and keep health_check_period at 30 seconds as I
>> > don't want to wait 140 seconds between checks, is this OK?
>> >
>> > I've tested with iptables blocking a node and it works, just checking
>> that
>> > there are no hidden gotchas?
>> >
>> >
>> > James Sewell,
>> > Solutions Architect
>> > ______________________________________
>> >
>> >
>> >  Level 2, 50 Queen St, Melbourne VIC 3000
>> >
>> > *P *(+61) 3 8370 8000  *W* www.lisasoft.com  *F *(+61) 3 8370 8099
>> >
>> > --
>> >
>> >
>> > ------------------------------
>> > The contents of this email are confidential and may be subject to legal
>> or
>> > professional privilege and copyright. No representation is made that this
>> > email is free of viruses or other defects. If you have received this
>> > communication in error, you may not copy or distribute any part of it or
>> > otherwise disclose its contents to anyone. Please advise the sender of
>> your
>> > incorrect receipt of this correspondence.
>>
> 
> 
> -- 
> 
> James Sewell,
> PostgreSQL Team Lead / Solutions Architect
> ______________________________________
> 
> 
>  Level 2, 50 Queen St, Melbourne VIC 3000
> 
> *P *(+61) 3 8370 8000  *W* www.lisasoft.com  *F *(+61) 3 8370 8099
> 
> -- 
> 
> 
> ------------------------------
> The contents of this email are confidential and may be subject to legal or 
> professional privilege and copyright. No representation is made that this 
> email is free of viruses or other defects. If you have received this 
> communication in error, you may not copy or distribute any part of it or 
> otherwise disclose its contents to anyone. Please advise the sender of your 
> incorrect receipt of this correspondence.