Отказоустойчивый кластер PostgreSQL: Patroni или BiHA

«Сделать кластер, чтобы база переживала отказ сервера» — задача, которая рано или поздно прилетает каждому DBA. Документация PostgreSQL честно предупреждает: средств обнаружения сбоя ведущего сервера и автоматического переключения СУБД не предоставляет, это отдано внешним инструментам. Отсюда два пути: поставить рядом с СУБД внешний оркестратор — де-факто стандарт здесь Patroni — или взять СУБД, в ядро которой кластерная логика уже встроена, как BiHA в Postgres Pro. Ниже — оба пути без агитации, с архитектурой, слабыми местами и деньгами.

Patroni или BiHA: сравнение в одной таблице

Если выбор — BiHA, кластер входит в лицензию Postgres Pro. Какая редакция нужна:

Как устроена репликация PostgreSQL

И Patroni, и BiHA управляют одной и той же механикой — физической потоковой репликацией PostgreSQL. Ведущий сервер непрерывно передаёт журнал предзаписи (WAL) на резервные, и каждый standby держит байт-в-байт копию всего экземпляра. Режим по умолчанию — асинхронный: реплика немного отстаёт, и при аварии последние транзакции могут не доехать. Синхронная репликация (synchronous_standby_names) не подтверждает коммит, пока его не примет реплика, — надёжнее, но каждая запись платит сетевой задержкой. Реплики при этом открыты на чтение (hot standby), а слоты репликации не дают ведущему удалить WAL, который ещё не забрала отставшая реплика.

Отдельный инструмент — логическая репликация: публикации и подписки переносят изменения выбранных таблиц на уровне строк и работают между разными мажорными версиями. Для failover она не используется — её место в миграциях и обновлениях; BiHA, например, задействует её при мажорном апгрейде кластера.

Но сама настройка репликации кластером ещё не является. Кластер — это ответ на четыре вопроса, которых нет в ядре PostgreSQL: кто следит за живостью лидера, кто и когда повышает реплику, как переключаются клиенты и как гарантировать, что писать не начнут два узла одновременно. Дальше — два способа ответить на эти вопросы.

Путь 1: Patroni — внешний оркестратор

Patroni — открытый проект под лицензией MIT, начатый в Zalando как форк Governor и ставший де-факто стандартом высокой доступности для ванильного PostgreSQL; поддерживаются версии с 9.3 по 18. На каждом узле рядом с PostgreSQL работает Python-демон: он запускает и конфигурирует СУБД, а состояние кластера хранит во внешнем распределённом хранилище конфигурации (DCS) — etcd, Consul, ZooKeeper или Kubernetes API. Лидерство определяется ключом лидера в DCS: пока ведущий успевает его обновлять, он лидер; ключ протух — оставшиеся узлы проводят выборы, и параметр maximum_lag_on_failover не даст повыситься слишком отставшей реплике.

Управляется кластер утилитой patronictl — в том числе плановый switchover без потери данных, — а REST API каждого узла отдаёт health-чеки, по которым HAProxy или другой балансировщик направляет запись на лидера. Это зрелый инструмент, проверенный в тысячах инсталляций, и если он у вас уже работает — это рабочая схема, а не «легаси».

Честно о том, где сложно:

• DCS — отдельный распределённый кластер из 3–5 узлов. Его тоже нужно развернуть, мониторить, обновлять и уметь чинить. На случай потери связи с DCS у Patroni есть отдельный режим DCS Failsafe Mode — но это ещё одна настройка, которую надо знать и тестировать.
• Строгая защита от split-brain требует watchdog на узлах — иначе зависший, но формально живой лидер может не самоустраниться вовремя.
• Patroni сам называет себя template — шаблоном, из которого HA-решение под свою инфраструктуру собираете вы. Это гибкость, но и обязанность держать экспертизу в команде: конфигурация, согласование обновлений трёх компонентов (PostgreSQL, Patroni, DCS) и регулярные учения по failover — на вашей стороне.

Путь 2: BiHA — кластер внутри СУБД

BiHA (Built-in High Availability) — собственная разработка Postgres Professional: расширение biha и служебные процессы в ядре превращают Postgres Pro в кластер с физической репликацией, автоматическим аварийным переключением и восстановлением после отказа узлов. Внешних компонентов нет: узлы обмениваются состоянием напрямую по управляющему TCP-каналу, и каждый узел знает о состоянии всех остальных.

Кластер собирается утилитой bihactl: init создаёт лидера, add добавляет последователей, параметры репликации при этом настраиваются автоматически. Штатно поддерживается и преобразование уже работающей потоковой репликации в BiHA-кластер: ведущий становится лидером, реплики — последователями.

При недоступности лидера оставшиеся узлы выбирают нового голосованием, и в голосовании учитывается длина WAL: повышается минимально отставший узел, что при асинхронной репликации означает минимальную потерю данных. Кворум настраивается. Старый лидер, изолированный по сети, принимает только читающие запросы — двух пишущих узлов не возникает; вернувшись в кластер, он автоматически становится последователем (вернуть ему лидерство можно вручную функцией set_leader).

Что ещё умеет кластер по документации вендора:

• Узел-рефери — арбитр для кластера из двух узлов, в том числе в режиме с репликацией данных: голосует в выборах и закрывает сценарий split-brain без третьего полноценного сервера.
• Каскадная репликация — реплики получают WAL через промежуточные узлы, разгружая лидера и каналы между ЦОД.
• Геораспределённость — BiHA-кластеры в разных площадках; многоуровневая катастрофоустойчивая схема (GDBiHA) пока помечена в документации как экспериментальная.
• Сервисный режим — пауза кластерной логики, чтобы применить изменения конфигурации на всех узлах.
• Мажорное обновление с минимальным простоем — bihactl автоматизирует миграцию кластера на новую основную версию: новый кластер догоняет старый по логической репликации и забирает нагрузку только после переключения.
• Callback-обработчики — SQL-функции на события кластера (например, смену лидера) для интеграции с мониторингом и внешними сервисами.

Клиенты переключаются штатными средствами: в строке подключения libpq или JDBC перечисляются все узлы кластера с параметром target_session_attrs=read-write — при смене лидера драйвер сам переподключается к пишущему узлу, а значение read-only направляет читающие сессии на реплики. Привычные прокси, пулеры и балансировщики тоже работают.

Что выбрать: три типовые ситуации

Есть команда с опытом Patroni. Если инфраструктура уже живёт на Patroni, учения по failover проходят штатно и экспертиза в команде есть, сам по себе BiHA — не повод ломать работающее. Тем более что техподдержка Postgres Professional покрывает и внешние средства кластеризации — Patroni, Stolon, Corosync/Pacemaker — когда СУБД у вас Postgres Pro.

Нужен один ответственный. Когда кластер строится с нуля и держать экспертизу по etcd и оркестратору некому, встроенный кластер снимает целый слой инфраструктуры: один вендор отвечает и за СУБД, и за failover, обновления приходят одним пакетом, а по инцидентам действует SLA техподдержки — для высшего приоритета реакция 15 минут и решение от 4 часов в режиме 24х7.

Регулируемый контур. Для госсистем и субъектов КИИ по 187-ФЗ решает сертификация: у Postgres Pro есть сертифицированные ФСТЭК редакции (Certified на базе Standard и Enterprise), и BiHA в них входит. Patroni — внешний открытый компонент, в сертифицированные конфигурации СУБД он не входит.

И честно: когда кластер не нужен. Если сервис переживёт простой в час и потерю нескольких минут транзакций, достаточно реплики с ручным повышением и выверенного резервного копирования. Автоматический failover сам добавляет сложность и точки отказа — включать его стоит там, где минуты простоя стоят дороже, чем сопровождение кластера.

Отдельный частый случай — кластер под базы 1С: про выбор редакции СУБД и особенности платформы есть отдельный разбор PostgreSQL для 1С.

Сколько стоит отказоустойчивый кластер

Patroni бесплатен, но владение — нет. К кластеру добавляются три узла DCS, стенд для учений и время инженеров на сопровождение трёх компонентов и дежурства. Это нормальная цена за гибкость — просто её надо честно закладывать в сравнение, а не сопоставлять «бесплатно» с ценой лицензии.

BiHA отдельно не покупается — это часть СУБД. Postgres Pro лицензируется по ядрам: считаются физические ядра сервера (для виртуальной машины — vCPU), включение Hyper-Threading количество лицензий не меняет, минимум на один сервер — 2 ядра. В отказоустойчивой конфигурации лицензируются все серверы кластера и все реплики — синхронные и асинхронные. Узел-рефери без пользовательских баз не лицензируется.

Пример расчёта: кластер «лидер + две реплики» на серверах по 8 ядер — это 24 ядерные лицензии. Схема «лидер + реплика + рефери» на тех же серверах — уже 16 лицензий: арбитр бесплатный. Бессрочная лицензия Postgres Pro Standard на ядро x86-64 стоит 195 006 ₽.

Для типовых нагрузок кластера достаточно Standard:

Active-active мультимастер, автоматическое исправление повреждённых страниц с реплики и встроенный прокси Proxima, который сам находит лидера BiHA-кластера, — это уже Enterprise:

Чем Standard отличается от Enterprise и от ванильного PostgreSQL по всем осям, а не только по кластеру, — в обзорной статье серии Postgres Pro или PostgreSQL.

Как купить Postgres Pro на юрлицо

Лицензии Postgres Pro для организаций продаёт ООО «МИГСОФТ»: счёт в рублях по безналичному расчёту, договор, закрывающие документы и комплект для тендера. СУБД входит в реестр российского ПО, поэтому лицензии продаются без НДС — как устроена льгота, разобрано в статье про НДС на программное обеспечение.

Лицензирование кластера — самое частое место ошибок в заявках: реплики лицензируются все, рефери — нет, на каждый сервер действует минимум в 2 ядра, у виртуализации свои правила. Пришлём расчёт лицензий под вашу конфигурацию кластера — бесплатно, в течение рабочего дня.

Самая частая позиция для кластера — бессрочная лицензия Postgres Pro Standard, считается по ядрам:

Рекомендуем в статье Лицензия СУБД Postgres Pro Standard на 1 ядро x86-64

PPT-86-LIC

195 006 ₽ НДС не облагается (ст. 149 НК РФ) — позиция в реестре российского ПО

Расчёт PDF В корзину В корзине Подробнее →

Частые вопросы