[pgpool-general: 5101] pgpool incorrectly thinks backend cluster is down

[manoj]

I have pgpool configured against two redshift backend clusters to do
parallel writes. Seemingly at random, pgpool determines that one or both
the clusters are down and stops accepting connections even when they are
not down. I have health check configured every 30 seconds but that does not
help as it checks heath and still determines they are down in pgpool_status
file. How is health status determined and written to the file
/var/log/pgpool/pgpool_status and why does pgpool think the clusters are
down when they are not?



I also tested read query routing and noticed they were being routed
randomly to the backend clusters. Is there a specific algorithm that pgpool
uses for read query routing?





My config parameters are below



backend_hostname0 = 'cluster1'

backend_port0 = 5439

backend_weight0 = 1

backend_data_directory0 = '/data1'

backend_flag0 = 'ALLOW_TO_FAILOVER'



backend_hostname1 = 'cluster2'

backend_port1 = 5439

backend_weight1 = 1

backend_data_directory1 = '/data1'

backend_flag1 = 'ALLOW_TO_FAILOVER'



#-----------------------------------------------------------
-------------------

# HEALTH CHECK

#-----------------------------------------------------------
-------------------



health_check_period = 30

                                   # Health check period

                                   # Disabled (0) by default

health_check_timeout = 20

                                   # Health check timeout

                                   # 0 means no timeout

health_check_user = 'username'

                                   # Health check user

health_check_password = 'password'

                                   # Password for health check user

health_check_max_retries = 10

                                   # Maximum number of times to retry a
failed health check before giving up.

health_check_retry_delay = 1

                                   # Amount of time to wait (in seconds)
between retries.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20161103/c376d76b/attachment-0001.html>