[pgpool-hackers: 4021] Re: Disabling failover when backend goes down or backend process killed
Tatsuo Ishii
ishii at sraoss.co.jp
Wed Sep 22 10:23:16 JST 2021
I have pushed this along with documents.
Note that the parameter name is "failover_on_backend_shutdown", the
default is off. So Pgpool-II 4.3 will change the default behavior in
this regard.
>> Hi Usama,
>>
>>>>> To overcome the problem, I would like to introduce a new switch called
>>>>> "enable_failover_on_backend_shutdown" for upcoming Pgpool-II 4.3. If
>>>>> enable_failover_on_backend_shutdown is on, pgpool will behave as it is
>>>>> now. If it is off, pgpool will not trigger failover when admin
>>>>> shutdowns the backend node or backend process is killed. Instead the
>>>>> session corresponding to the backend process will be terminated.
>>>>>
>>>>> Comments or suggestions are welcome.
>>>
>>> I think the default for the new parameter should be "off" because it
>>> will help newcommers to Pgpool-II. The current behavior has been
>>> bringing confusions to such users.
>>> For example:
>>> https://www.pgpool.net/mantisbt/view.php?id=726
>>
>> In the yesterday's off mailing list discussion, you suggested that we
>> want to generalize the feature: so that users can specify error code
>> which should be avoided failover, for example max_connections error.
>>
>> I have investigated the code and found that the only error codes which
>> triggers failover are:
>>
>> #define ADMIN_SHUTDOWN_ERROR_CODE "57P01"
>> #define CRASH_SHUTDOWN_ERROR_CODE "57P02"
>>
>> i.e. max_connections error is not handled in this code path. It's
>> actually handled by health check. The health check process just tries
>> to connect to backend and if it fails by whatever reason, including
>> max_connections error, it triggers failover after specified
>> retries. We could enhance this so that max_connections error does not
>> trigger failover in the health check, but it is another story.
>>
>> Am I missing something?
>
> Note that if the health check is disable or pgpool tries to connect to
> backend and fails because of max_connections error (while the health
> check retires), the client gets but no failover happens:
>
> FATAL: sorry, too many clients already
>
> So far so good. However logs are not so good:
>
> 2021-09-04 11:49:22.967: child pid 661457: ERROR: backend authentication failed
> 2021-09-04 11:49:22.967: child pid 661457: DETAIL: backend response with kind 'E' when expecting 'R'
> 2021-09-04 11:49:22.967: child pid 661457: HINT: This issue can be caused by version mismatch (current version 3)
> 2021-09-04 11:49:22.968: child pid 661457: ERROR: backend authentication failed
> 2021-09-04 11:49:22.968: child pid 661457: DETAIL: backend response with kind 'E' when expecting 'R'
> 2021-09-04 11:49:22.968: child pid 661457: HINT: This issue can be caused by version mismatch (current version 2)
>
> In this case the cause of error is apparently not protocol version
> mismatch. We need to enhance this in the future.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
> _______________________________________________
> pgpool-hackers mailing list
> pgpool-hackers at pgpool.net
> http://www.pgpool.net/mailman/listinfo/pgpool-hackers
More information about the pgpool-hackers
mailing list