Это защищает систему от Split-Brain — ситуации, когда в кластере появляются два пишущих узла.
В крупных инсталляциях кластер часто живет в нескольких ЦОДах: основная и DR-площадка, резервный контур, реплики для отчетов, аналитики или копий данных для 1С.
Здесь классическая схема «звезда» начинает мешать. Лидер раздает WAL каждой реплике напрямую, один и тот же поток несколько раз уходит по межцодовым каналам, растет число walsender, а новые реплики нагружают основной узел.
BiHA решает эту задачу каскадной репликацией.
🔸 Вместо «звезды» появляется дерево: лидер отправляет WAL узлу-ретранслятору, а тот раздает данные дальше — например, локальным репликам внутри резервного ЦОДа.
Источник выбирает алгоритм Best Follower. Реплика подключается не к первому доступному узлу, а к наиболее подходящему — с учетом роли и свежести данных по LSN.
Что это дает бизнесу:
☑️ Экономит сетевые каналы
Между ЦОДами идет меньше трафика репликации. Можно снизить затраты на сеть или не расширять существующие каналы.
☑️ Масштабирует чтение без просадки лидера
Новые реплики не подключаются все разом к основному узлу. Каждые 3-5 реплик можно выстроить в отдельную ветку каскада.
☑️ Восстанавливается без администратора
Если ретранслятор падает, BiHA перестраивает дерево. Реплики находят новый источник и продолжают работу.
☑️ Контролирует переключение между ЦОДами
can_be_leader=false помогает держать резервный ЦОД в режиме горячего standby и переключаться вручную, когда сервисы готовы к переходу.☑️ Сокращает внешние зависимости
BiHA встроена в Postgres Pro Enterprise: меньше отдельных компонентов, процессов управления HA и интеграционных скриптов.
🔗 Читайте на Хабре, как BiHA помогает строить геораспределенные кластеры Postgres Pro: с понятной топологией, меньшей нагрузкой на лидер, экономным трафиком между ЦОДами и автоматическим восстановлением после сбоев.
📢 Читайте нас в MAX