У меня есть два сервера, настроенных с PG Pool, чтобы создать настройку HA для веб-приложения.
PGPool и postgres работают на обоих серверах, используя потоковую репликацию с сервера 1 на сервер 2. Веб-приложение на каждой машине подключается к PgPool, который затем отправляет запрос текущему мастеру. Он настроен на автоматическое переключение при отказе в случае прерывания соединения с базой данных, который запускает настраиваемый сценарий аварийного переключения для понижения уровня сервера 1 до подчиненного и повышения уровня сервера 2 до главного.
Сегодня утром произошло то, что на 2 минуты сеть вышла из строя, что означает, что ни один экземпляр PGPool не мог разговаривать друг с другом, поэтому каждый PGPool думал, что другая машина не работает.
Сервер 1 - продолжил в качестве главного, отключив сервер 2
Сервер 2 - инициировал аварийное переключение, отключив сервер 1 и сделав себя мастером
Поскольку сеть не работала, команда аварийного переключения не могла пройти к серверу 1, чтобы сделать его подчиненным, и наоборот. Итак, когда через 2 минуты сеть восстановилась, у меня было два сервера, которые оба считали себя главными.
PgPool, похоже, не имеет автоматической команды восстановления после сбоя, которую можно было бы использовать, чтобы заставить сервер 1 снова стать мастером при повторном подключении сети, что является единственным реальным решением, которое я могу придумать.
У меня вопрос: как мне поступить в этой ситуации? Это вообще правильная архитектура для этой установки? Конечно, это распространенный сценарий, я не могу понять, как это можно исправить.
Изменить: было бы целесообразно запустить pgpool под виртуальным IP-адресом под linux-ha? Который мог решайте проблемы, и у меня уже есть это для общедоступного IP-адреса - таким образом, только один экземпляр pgpool получает доступ с любой машины.
Во-первых, я думаю, что у pgpool2 есть команда восстановления после сбоя, но в этом случае это не поможет. Проблема в том, что возникнет хаос, если обе машины будут считать себя хозяевами. Более того, здесь у вас был простой случай: отключилась сеть. Что делать, если сеть разделена? То есть обе машины подключены, но как-то теряют связь друг с другом. В этом случае обе машины станут главными и будут обслуживать разных клиентов, и у вас будет разветвленная база данных. Это более редкий случай, но уверены ли вы, что настолько маловероятно, что вы готовы рискнуть в результате хаоса?
Альтернативой может быть следующее:
+- master db
|
------ pgpool ------+
|
+- hot standby
Однако в этом случае у вас есть единственная точка отказа, pgpool, которая вам, вероятно, не нужна. Я знаю только два способа решить эту проблему. Самый простой - только продвигать резервный сервер для управления вручную, и это применимо к вашей архитектуре. Ваши приложения должны будут перейти в режим только для чтения до вмешательства человека.
Второй способ - иметь кворумы. Одна из архитектур, которая может работать, такова:
+--- pgpool standing by -+ +- master db
| | |
failover ip -+--- active pgpool -+----+- hot standby 1
| | |
+--- pgpool standing by -+ +- hot standby 2
|
+- hot standby 3
(as many standby servers as
you want, so that you have
read-only load balancing)
Три пула pgpools работают на трех разных машинах, каждая со своим собственным IP-адресом, но они также предоставляют дополнительный IP-адрес аварийного переключения, который используется только активной машиной, и он используется клиентами. Если активный pgpool выходит из строя, его берет на себя резервный pgpool. Этого можно добиться с помощью heartbeat.
Чтобы преобразовать горячий резерв в мастеринг, кворум pgpools (то есть, по крайней мере, два из трех) должен принять решение об этом; и они выполнят решение только после задержки, скажем, в 10 секунд после принятия решения. Кроме того, активный pgpool может не продолжать использовать существующий главный db в течение более 10 секунд без получения подтверждения хотя бы от другого pgpool (это сделано для защиты от случая, когда два резервных pgpool теряют соединение с активным pgpool и к мастер в то же время продвигает горячий резерв к мастеру, но активный pgpool продолжает использовать старый мастер).
На самом деле третий pgpool не должен участвовать в резервном IP-адресе, а просто присутствовать там, чтобы помогать кворуму. Кроме того, я не знаю, достаточно ли у pgpool возможностей для этого. Может тебе нужен еще один демон. Более общая архитектура такова:
+--- active pgpool -+ +- master db
| | |
failover ip -+ -+----------+- hot standby 1
| | |
+--- pgpool standing by -+ +---+- hot standby 2
| |
| +- hot standby 3
monitoring daemon 1 ---+ |
| |
monitoring daemon 2 ---+------+
|
monitoring daemon 3 ---+
В этом случае балансировка нагрузки, выполняемая pgpool, отделена от мониторинга и перехода от режима ожидания к мастеру. Обратите внимание, что вы можете разместить pgpools, серверы баз данных и демоны мониторинга на одном компьютере, но два pgpools должны находиться на двух разных машинах, а три демона мониторинга должны быть на трех разных машинах. Обратите внимание, что я не знаю, существует ли готовый демон мониторинга со всеми необходимыми функциями.
Детали могут быть изменены, но я думаю, что если вы сделаете автоматическое продвижение из режима ожидания в мастер без использования кворума, у вас возникнут проблемы.
Это вообще правильная архитектура для этой установки? Конечно, это распространенный сценарий, я не могу понять, как это можно исправить.
Отказ от ответственности: я не использовал pgpool, но знаю, что он делает.
В программном обеспечении для кластеризации обычно не требуются автоматические операции, которые могут нарушать правила параллелизма (например, что-то должно быть в сети только в одном месте), когда кластеру известно о состоянии менее половины узлов. Это предотвращает состояние расщепления мозга, подобное тому, которое вы испытывали. В двухузловом кластере это будет означать, что в случае потери сетевого взаимодействия между двумя узлами не должно происходить автоматического переключения при отказе. Человек должен принять решение об аварийном переключении, проверив, что это правильное действие, в зависимости от того, находится ли «другой» узел в автономном режиме, или допустив, что может быть потеря нереплицированных транзакций. Я не знаю, можно ли это настроить в pgpool.
Если ваши серверы находятся в одной локальной сети (низкая задержка в сети для доступа друг к другу), вы можете рассмотреть возможность запуска pgpool в режиме репликации с несколькими мастерами. У вас возникнут небольшие накладные расходы, связанные с необходимостью одновременного обновления двух баз данных.
В случае одного сбоя системы pgpool может продолжить предоставление доступа через активный узел. После восстановления системы вы можете запустить онлайн-восстановление в pgpool, чтобы активировать другой узел.