Как лучше организовать отказоустойчивый кластер PostgreSQL?
Потребовалось развернуть постгрес 9.6 под 1С. Взял их дистрибутив, развернул на ВМ под centos7, настроил репликацию на вторую такую же, теперь думаю о том, как из этого правильно сделать кластер. Хостов в системе (гипервизоров) всего два, stonith недоступен (или я его не умею готовить, но в двуххостовом кластере при разрыве сети происходит либо stonith deathmatch либо split brain, так что он мало что решает), так что пока мысли только о какой-нибудь конфигурации с удаленной третьей нодой в другой сети. В то же время из хостов собран кластер Microsoft, на котором можно поднимать ВМки, то есть можно формально сделать ВМ с постгресом кластерной и решать вопросы падения ресурсов через кластерную службу (в предположении, что падать будет не постгрес, а аппаратная часть). Третий хост в кластер не поставить - не хватает FC-подключений к хранилищу, поставить отдельно можно, но дорого (с) начальник. Стоит ли в таком раскладе вообще маяться с отказоустойчивостью, а если её делать, то как именно? Желательно, чтобы потеря одной ВМ или одного гипервизора не отключала постгрес целиком и не приводила к потере данных.
В итоге сделал так:
Три ВМ, одна кластерная на хранилище с ролью master, две на локальных дисках гипервизоров с ролями hot standby, настроил потоковую репликацию через wal sender в режиме "записать одну копию, потом завершать транзакцию" (параметр synchronous_standby_names = '1 (*)' ), и получил примерно искомое - в случае падения одного из гипервизоров ложится одна реплика и возможно мастер, но мастер поднимается на второй ноде и с оставшейся репликой вполне успешно сохраняет данные. Узким местом остается сам мастер, если в нем какое-либо повреждение, постгрес ляжет как целое, но по крайней мере можно будет вытащить данные с реплики и поднять мастер ещё раз.
Если будет время таки гляньте stolon, можно добиться автоматической работы при смене мастеров.
У меня 4 ноды, 3 в одном ДЦ и 1 во втором ДЦ. из 3 нод, одна мастер, 1 синхронная реплика одна асинхронная. Все переключения происходят автоматом.
Все работает поверх докер сворм, что позволяет почти нулевое администрирование, сворм сам балансирует контейнеры по нодам.
Мне не подошло то, что все ВМ должны быть в нем равноправными, плюс минимум три надо - а у меня хостов максимум два, ибо нет денег (ц). Но да, рассматривал именно Stolon как вариант управления постгресом.
Существует спектр решений. Проблема в том, что надо выбрать наиболее подходящую для вас. Тут кратко расписаны варианты postgresql.leopard.in.ua/html
У заказчика были специфические требования. Ему нужно было, чтобы решение работало в docker swarm.
Рассматривались RepMgr, Patroni, Stolon. Больше всего понравился https://github.com/sorintlab/stolon.
Пол года полёта, база 30 гиг. около 50 пользователей. Полёт нормальный.
СтОит или нет зависит от требований.
Не зная этих требований нельзя ответить, что правильнее.
У кластера есть вполне определённые цели и, вполне возможно, что вы занимаетесь оверинжинирингом и вам достаточно будет просто бекапы снимать с правильной частотой без всяких кластеров.
