[pgpool-general: 3548] Re: health_check_period formula
Tatsuo Ishii
ishii at postgresql.org
Wed Mar 18 18:21:18 JST 2015
>> > 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.
More information about the pgpool-general
mailing list