pgpool-II: можно ли назначить узел мастером более одного раза?

У меня есть такая конфигурация с pgpool: "Host-1" master и "Host-2" slave, если "Host-1" выключается, pgpool правильно продвигает "Host-2" в качестве главного; но затем, если "Host-1" возвращается, pgpool не знает об этом, и, если "Host-2" выключается, pgpool не продвигает "Host-1" в качестве главного, даже если "Host-1" онлайн. Я включил health_check, но это кажется совершенно бесполезным, потому что состояние «Host-1» (после того, как он становится активным) всегда равно 3 = «Node is down».

Это результат выполнения команды "show pool_nodes" во время событий:

-> Исходная ситуация: «Хост-1» UP (мастер), «Host-2» UP (подчиненный)

 node_id | hostname | port | status | lb_weight |  role
---------+----------+------+--------+-----------+--------
 0       | Host-1    | 5432 | 2      | nan       | master
 1       | Host-2    | 5432 | 1      | nan       | slave

-> узел 0 отключается: «Узел-1» ВНИЗ, «Узел-2» ВВЕРХ

 node_id | hostname | port | status | lb_weight |  role
---------+----------+------+--------+-----------+--------
 0       | Host-1    | 5432 | 3      | nan       | slave
 1       | Host-2    | 5432 | 2      | nan       | master

-> узел 0 возвращает: "Хост-1" ВВЕРХ, "Хост-2" ВВЕРХ

 node_id | hostname | port | status | lb_weight |  role
---------+----------+------+--------+-----------+--------
 0       | Host-1    | 5432 | 3      | nan       | slave
 1       | Host-2    | 5432 | 2      | nan       | master

обратите внимание, что статус «Host-1» равен 3, что означает «Node is down».

-> узел 1 отключается: "Host-1" UP, "Host-2" DOWN: в этот момент я не могу подключиться к базе данных, даже если узел 0 запущен и работает!

Что мне нужно сделать, чтобы разрешить pgpool повысить роль ведущего узла 0 в другой раз? Если это может быть полезно, это разделы «Настройки подключения к бэкэнду» и «ПРОВЕРКА ЗДОРОВЬЯ» моего pgpool.conf:

# - Backend Connection Settings -

backend_hostname0 = 'Host-1'
                                   # Host name or IP address to connect to for backend 0
backend_port0 = 5432
                                   # Port number for backend 0
#backend_weight0 = 1
                                   # Weight for backend 0 (only in load balancing mode)
#backend_data_directory0 = '/data'
                                   # Data directory for backend 0
backend_flag0 = 'ALLOW_TO_FAILOVER'
                                   # Controls various backend behavior
                                   # ALLOW_TO_FAILOVER or DISALLOW_TO_FAILOVER

backend_hostname1 = 'Host-2'
                                   # Host name or IP address to connect to for backend 0
backend_port1 = 5432
                                   # Port number for backend 0
#backend_weight1 = 1
                                   # Weight for backend 0 (only in load balancing mode)
#backend_data_directory1 = '/data'
                                   # Data directory for backend 0
backend_flag1 = 'ALLOW_TO_FAILOVER'
                                   # Controls various backend behavior
                                   # ALLOW_TO_FAILOVER or DISALLOW_TO_FAILOVER

#------------------------------------------------------------------------------
# HEALTH CHECK
#------------------------------------------------------------------------------

health_check_period = 10
                                   # Health check period
                                   # Disabled (0) by default
health_check_timeout = 20
                                   # Health check timeout
                                   # 0 means no timeout
health_check_user = 'admin'
                                   # Health check user
health_check_password = '12345'
                                   # 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.

postgresql database fallback pgpool
person Gianluca    schedule 05.10.2013    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Вы должны поднять вверх подчиненный узел, прежде чем его можно будет повысить. В вашем случае это означает использование Slony для полной отработки отказа и восстановления прежнего Мастера в качестве нового Подчиненного.

Основная проблема заключается в том, что записи, записанные на новый главный сервер, должны быть реплицированы на старые, прежде чем вы сможете вернуться в исходное состояние. Это в первую очередь проблема Slony. После того, как вы убедитесь, что Slony работает и все реплицируется, вы можете устранить неполадки на стороне pgpool, но не раньше (а затем вам может потребоваться повторно подключить его к PGPool). Когда PGPool находится в режиме Master / Slave, PGPool является вторичным по отношению к любой другой системе репликации, которую вы используете.

person Chris Travers    schedule 24.11.2013
comment
Это не имеет ничего общего со Слони. Как только репликация будет восстановлена, pgpool не заметит этого, но ему необходимо сообщить, что узел работает. Как указывает ответ @Ochko, сделайте это с прикреплением - даже если он кажется прикрепленным, его необходимо снова прикрепить. Увидел это сегодня вечером на сервере pgpool и чесал голову. - person Richard Michael; 03.07.2014

arrow_upward
3
arrow_downward

После того, как ваш подчиненный узел будет запущен и репликация заработает, вам необходимо повторно подключить узел к pgpool.

$ pcp_attach_node 10 pgpool_host 9898 admin _pcp_passwd_ 0

Последний аргумент - это идентификатор узла, для вашего случая это 0.

См. http://www.pgpool.net/docs/latest/pgpool-en.html#pcp_attach_node подробнее.

person Ochko    schedule 11.12.2013