☁️ Один сервер PostgreSQL может стать точкой отказа для всей почтовой системы
Если PostgreSQL используется почтовым сервером, его отказ затрагивает не только базу. Вместе с ней могут остановиться переписка, согласования и другие рабочие процессы. Поэтому для критичной инфраструктуры недостаточно просто иметь резервную копию базы: важно обеспечить автоматическое переключение на рабочий узел.
Один из вариантов такой архитектуры можно собрать всего на трёх виртуальных машинах.
▫️ Patroni следит за состоянием PostgreSQL и при отказе основного узла автоматически переводит реплику в роль нового мастера.
▫️ etcd хранит состояние кластера и обеспечивает консенсус. Кворум из трёх узлов защищает от ситуации, когда несколько серверов одновременно считают себя главным.
▫️ HAProxy становится единой точкой входа. Он определяет через Patroni, какой узел сейчас является мастером, и направляет подключения только к нему. Почтовому серверу при этом не нужно знать о топологии базы.
Получается следующая схема:
PostgreSQL → репликация → автоматический failover
etcd → определяет лидера и обеспечивает кворум
HAProxy → направляет подключения на актуальный мастер
При этом есть важный нюанс с репликацией. В асинхронном режиме кластер работает производительнее, но при внезапном отказе мастера можно потерять последние транзакции, которые ещё не успели попасть на реплику. Если такая потеря недопустима, Patroni поддерживает синхронную репликацию. В этом случае запись может остановиться при недоступности реплики.
То есть при настройке отказоустойчивости приходится выбирать между доступностью системы и гарантией сохранности последних данных.
Для почтовой системы это особенно важно: мало просто иметь два узла PostgreSQL. Нужно решить сразу три задачи: автоматически выбрать нового мастера, не допустить split-brain и сохранить единую точку подключения для приложения.
В блоге мы собрали готовую реализацию этой схемы для RuPost: три ВМ, PostgreSQL, Patroni, etcd и HAProxy. Конфигурации, systemd-юниты и вспомогательные скрипты вынесли в открытый репозиторий, чтобы кластер можно было развернуть по готовым шаблонам.
Если PostgreSQL используется почтовым сервером, его отказ затрагивает не только базу. Вместе с ней могут остановиться переписка, согласования и другие рабочие процессы. Поэтому для критичной инфраструктуры недостаточно просто иметь резервную копию базы: важно обеспечить автоматическое переключение на рабочий узел.
Один из вариантов такой архитектуры можно собрать всего на трёх виртуальных машинах.
▫️ Patroni следит за состоянием PostgreSQL и при отказе основного узла автоматически переводит реплику в роль нового мастера.
▫️ etcd хранит состояние кластера и обеспечивает консенсус. Кворум из трёх узлов защищает от ситуации, когда несколько серверов одновременно считают себя главным.
▫️ HAProxy становится единой точкой входа. Он определяет через Patroni, какой узел сейчас является мастером, и направляет подключения только к нему. Почтовому серверу при этом не нужно знать о топологии базы.
Получается следующая схема:
PostgreSQL → репликация → автоматический failover
etcd → определяет лидера и обеспечивает кворум
HAProxy → направляет подключения на актуальный мастер
При этом есть важный нюанс с репликацией. В асинхронном режиме кластер работает производительнее, но при внезапном отказе мастера можно потерять последние транзакции, которые ещё не успели попасть на реплику. Если такая потеря недопустима, Patroni поддерживает синхронную репликацию. В этом случае запись может остановиться при недоступности реплики.
То есть при настройке отказоустойчивости приходится выбирать между доступностью системы и гарантией сохранности последних данных.
Для почтовой системы это особенно важно: мало просто иметь два узла PostgreSQL. Нужно решить сразу три задачи: автоматически выбрать нового мастера, не допустить split-brain и сохранить единую точку подключения для приложения.
В блоге мы собрали готовую реализацию этой схемы для RuPost: три ВМ, PostgreSQL, Patroni, etcd и HAProxy. Конфигурации, systemd-юниты и вспомогательные скрипты вынесли в открытый репозиторий, чтобы кластер можно было развернуть по готовым шаблонам.