24.08.2026 17:06
sqlmaster 13 10000 Источник

PostgreSQL: Как собрать HA-кластер без «комитетов» и лишних сущностей

Если вы когда-нибудь настраивали Patroni, то знаете это чувство: чтобы просто следить за одной базой, вам нужно построить вокруг неё целый город. Тут у нас etcd, там Consul, здесь зоопарк зависимостей, а вон там отдельный бюджет на железо под систему управления. Это напоминает попытку установить охранную систему, которая потребляет больше электричества, чем защищаемый объект.

Классика HA строится на «централизованном консенсусе». Это когда три сервера управления спорят между собой, кто из двух серверов базы данных сейчас главный. Я решил, что пора перестать плодить сущности.

Познакомьтесь с GFM (Gorgona Failover Manager). Это менеджер отказоустойчивости, который работает на принципах P2P-меша.

В чем фокус?

Главная проблема Patroni, ему нужен DCS (Distributed Consensus Store). Это внешняя точка отказа, которую саму надо резервировать. GFM же использует Gorgona Mesh, децентрализованную сеть, где узлы общаются друг с другом напрямую через зашифрованные каналы.

Никаких etcd. Никаких «совещаний директоров». Каждая нода сама себе хозяин.

Преимущества для тех, кто ценит чистоту кода и железа:

  1. Изоляция инстансов. На одном мощном сервере можно поднять X кластеров Postgres. У каждого будет свой cluster_id, свои порты и свои лимиты памяти. GFM не путается в ногах у соседа благодаря Systemd-шаблонам и уникальным лок-файлам.

  2. Математика вместо голосования. Лидер выбирается не по «симпатиям» алгоритма Рафт, а по LSN (Log Sequence Number). Кто реально дальше всех продвинулся по записи данных — тот и мастер. Если LSN одинаковый, смотрим на имя хоста в алфавитном порядке. Просто, детерминировано, надежно.

  3. Безопасность. Шифрование здесь не «опция», которую надо настраивать три дня с сертификатами, а фундамент. Весь управляющий трафик идет внутри P2P-меша «из коробки».

Секретное оружие: Gorgonad в памяти

А теперь вишенка на торте. У gorgonad (сердце нашего меша) есть режим работы полностью в памяти.

Зачем писать сообщения управления на диск, создавая лишнюю I/O нагрузку и оставляя следы? В этом режиме база событий и очередей живет только в RAM. Если питание вырубится, она просто исчезнет, не оставив мусора. Это дает бешеную скорость отклика: управляющие сигналы пролетают по сети быстрее, чем диск успеет «чихнуть». Для систем, где задержки критичны (привет, высоконагруженная 1С), это спасение.

Почему это важно для 1С и не только?

Админы 1С боятся Postgres, потому что он кажется им хрупким. С GFM всё становится предсказуемым. Мы добавили автоматическую привязку к NUMA-узлам и жесткую изоляцию ресурсов через cgroups. Базы больше не «воруют» память друг у друга, а виртуальный IP (VIP) переезжает за мастером автоматически.

Итог простой: Если вам нравится администрировать облако из десяти сервисов ради одной базы Patroni ваш выбор. Если вам нужно, чтобы база просто работала, переключалась как часы и не требовала «комитета по кворуму» на каждом шагу, попробуйте P2P-подход.

Это работает быстро, весит мало и не задает лишних вопросов. Как раз в моем вкусе.

https://github.com/psqlmaster/gorgona/blob/master/plugins/gfm/readme.md
https://deepwiki.com/psqlmaster/gorgona/6.5-gfm:-gorgona-failover-manager-for-postgresql

Перейти на панель управления можно по следующей ссылке
Для входа используйте следующие учетные данные:
Имя пользователя: demo
Пароль: demo

Что внутри стека:

  • GFM: Python-демон управления.

  • Gorgonad + Gorgona: P2P Mesh сервер / клиент.

  • Shell-скрипты: Smart-ребилд (pg_rewind + pg_basebackup).

  • Никакого etcd. Вообще.

Stay decentralized.

Комментарии (13)


  1. sha256man
    24.08.2026 19:00
    #30361632

    Jepsen уже потестил? )

    Есть ещё use-case - шиппить поцгрес не сильно продвинутым заказчикам в составе своего ПО. И отсутствие в поцгресе штатного HA это просто катастрофа.


    1. sqlmaster Автор
      24.08.2026 19:00
      #30361654

      думаю опечатка? шиппить > шилить
      обижаете, как можно не тестить) привет, по ссылке есть демо 2х кластеров
      но у gfm есть реальное преимущество witness можно хоть на роутер под arm поставить
      надо делать сборку под 1С и продавать установку и поддержку, но хз время где взять


  1. sha256man
    24.08.2026 19:00
    #30361652

    А можно прокомментить четыре замечания chatgpt? (навскидку - всё по делу)

    LSN-based leader selection is not a substitute for distributed consensus + fencing.

    The biggest problem: split-brain

    That sounds reasonable until you consider a network partition.

    2.

    The witness is particularly important

    Interestingly, GFM actually has a witness role in the configuration example:

    192.168.1.170
192.168.1.171
192.168.1.172 witness

    But from the documented election algorithm, I don't see the necessary quorum semantics.

    The README describes:

    1. highest LSN wins;

    2. hostname breaks ties;

    3. loser fences itself.

    That's not equivalent to quorum.

    3. LSN is also the wrong primitive for leader election

    So a proper HA system needs something closer to:

    cluster term / epoch
      +
quorum
      +
leader lease
      +
fencing
      +
Postgres state

    4 pg_rewind doesn't make this safe

    pg_rewind is a recovery mechanism, not a split-brain prevention mechanism.


    1. sqlmaster Автор
      24.08.2026 19:00
      #30361662

      привет, можно конечно, конечно без сомнений никак низя, когда идея возникла у меня тоже были сомнения что не заработает, но оно работает, в демо можно зайти и потыкать, доступ если в поле ввода где каналы с *remote если нажать выйдет панель управления где можно команды засылать

      ps: все аргументы gpt были в процессе уже, и были сплитбрейны, все это полечено, скормите ему https://deepwiki.com/psqlmaster/gorgona/6.5-gfm:-gorgona-failover-manager-for-postgresql


  1. sqlmaster Автор
    24.08.2026 19:00
    #30361666

    а вообще было бы идеально найти кого-нибудь кто поможет, и мы будем это вместе продавать как готовый кейс)


  1. sqlmaster Автор
    24.08.2026 19:00
    #30361726

    Отвечу на ключевые вопросы, чтобы прояснить механику. В основе лежит кластер gorgonad, который выдает четкую последовательность событий через номера Snowflake.

    При таком строгом порядке всё упрощается: у каждого действия есть свой уникальный и неизменный номер, что создает одну прямую линию событий. Общая история в этой схеме, это тот самый номер, на котором запасной сервер потерял связь с главным. Поскольку мастер всегда один, запасному серверу не нужно ничего выдумывать: он просто ждет появления в сети следующего номера по порядку и приклеивает его к своей цепочке. Если же вдруг запасной сервер по ошибке сам создал какие-то номера, система сразу увидит, что они чужие и не попадают в общую очередь. В этом случае он просто удаляет свои неверные записи и возвращается к настоящей цепочке мастера. Благодаря такой строгой очереди серверы всегда точно знают, кто отстал, а кто идет верно, и общая история становится фундаментом, на который новые события достраиваются строго по порядку.

    Единственный момент, который сейчас в процессе доработки, это роль витнеса(арбитра) для полной защиты от разделения сети (сплит-брейна). Чтобы система была абсолютно пуленепробиваемой, нужно внедрить логику кворума: сервер не сможет объявить себя главным, если не видит в сети как минимум еще одного участника, второго сервера или витнеса. Это дополнение сейчас в работе и оно окончательно закроет вопрос безопасности, делая консенсус абсолютно надежным в любых ситуациях.


    1. sqlmaster Автор
      24.08.2026 19:00
      #30361944

      в консоли демо, можно "поуправлять" установив фокус в поле ввода внизу, вход в консоль описана в конце статьи


    1. Debrainer
      24.08.2026 19:00
      #30362004

      Так это режим safe_mode=true у патрони, который точно также проверяет p2p доступность всех других хостов БД заявленных в кластере и при котором можно например потушить бд на узле или перевести старого мастера в ридонли во избежание рассинхрона между базами, например при пропадании сети и риске сплит брейна.

      Но я так и не понял чем кластер Gorgonad с узлами расположенными на узлах с бд концептуально отличается от кластера etcd также с совмещенными узлами на узлах с бд.

      Ну кроме того что в продакшене так совмещать не рекомендуют ибо борьба за ресурсы, зависимость друг от друга и всё такое...


      1. sqlmaster Автор
        24.08.2026 19:00
        #30362626

        Привет,
        Gorgonad (Децентрализованный меш): Здесь нет центрального ключа. Мастер это тот, кто вещает в сеть свой пульс (LEADER_STATUS), и пока другие узлы слышат этот пульс и согласны с его приоритетом (LSN/Имя), они признают его лидером. Источник правды сумма мнений всех узлов в меше.

        etcd: Работает на алгоритме Raft. Ему жизненно необходим fsync на диск при каждой записи лога транзакции Raft. Если на узле, где стоит etcd, «ляжет» диск или возникнет IO-wait, весь кластер БД может встать, так как Patroni не сможет продлить аренду ключа.

        Gorgonad: Работает полностью в RAM(опцианально, может к примеру только один из узлов быть на диске, любые комбинации). Ему всё равно на состояние дисков. Это делает его в десятки раз быстрее в принятии решений и гораздо менее капризным к производительности локального железа.

        Gorgonad: Изначально проектировался для работы через интернет и нестабильные каналы. Использует асинхронную модель доставки сообщений с шифрованием. Он терпеливее к сетевым лагам, так как GFM ориентируется на интервалы (timeouts), а не на жесткую синхронность Raft-шагов

        Концептуально etcd: это Строгий Судья, который сидит в центре и раздает разрешения. А Gorgonad: это Защищенная Рация, по которой узлы сами договариваются, кто сегодня главный, проверяя видимость друг друга.

        Если etcd, это консистентность через жесткую фиксацию состояния на дисках (Raft), то Gorgonad обеспечивает её через мгновенный сетевой кворум и LSN-контроль в памяти, исключая риск записи на отстающих или изолированных узлах


        1. Debrainer
          24.08.2026 19:00
          #30362772

          Давайте на примере.

          У вас 7 георазнесенных нод с горгоной.

          И вот в один момент падает сеть так что 3 ноды видят только друг друга, а 4 других только друг друга. Что произойдёт с общим кластером? Где будет выбран или останется мастер и на основании чего? Что произойдёт с другими узлами и на основании чего? Усложню, если на одном из узлов процесс демона завис, а бд жива и являлась мастером?

          Какие механизмы защиты от "моргания" сети предусмотрены?

          Реальные тесты стрессоустойчивости проводились? Можно увидеть результаты по кейсам?


          1. sqlmaster Автор
            24.08.2026 19:00
            #30362934

            Разберём сценарий строго по коду gfm.py (и описанию из репозитория Gorgona/GFM).
            Используем стандартную конфигурацию: quorum_total_nodes = 7, все 7 узлов перечислены в quorum_nodes, majority = (7 // 2) + 1 = 4.

            1. Partition 3 ↔ 4 (сеть разорвалась)

            Что происходит с кворумом

            needed = (self.quorum_total_nodes // 2) + 1   # = 4
reachable_count = 1  # сам себя
# + проверка TCP-портов остальных из quorum_nodes

            Группа Достижимых узлов Кворум? 4 ноды 4 Да 3 ноды 3 Нет

            Кворум считается только по TCP-доступности портов из quorum_nodes, а не по mesh-сообщениям Gorgona. Mesh может быть «живым» внутри группы, но это не влияет на has_network_quorum().

            Случай A: текущий LEADER оказался в группе из 4

            1. Лидер продолжает видеть quorum → остаётся LEADER, шлёт LEADER_STATUS.

            2. Три узла в меньшинстве:

              • перестают получать heartbeat;

              • через election_timeout пытаются начать выборы;

              • start_election() сразу abort’ится:

                if not self.has_network_quorum():
    self.log("ELECTION ABORTED: No network quorum...")
    return

            3. Если среди тройки кто-то был LEADER — он сам себя снесёт:

              if self.role == "LEADER":
    if not self.has_network_quorum():
        self.demote_node("FENCING: Isolated from quorum. Stopping to prevent Split-Brain.")

              → systemctl stop <pg_service> → роль STANDBY.

            Итог: мастер остаётся в majority (4). Minority не может выбрать нового мастера и не может остаться старым.

            Случай B: текущий LEADER оказался в группе из 3

            1. Лидер теряет quorum → сам себя fencing’ует (stop PostgreSQL).

            2. В группе из 4:

              • silence_time растёт;

              • через election_timeout узлы с lsn > 0 идут в start_election();

              • у них quorum есть → один из них (с наибольшим LSN, при равенстве — с меньшим hostname) становится CANDIDATE → через 10 с promote.

            3. Тройка остаётся без мастера и без права на выборы.

            Итог: мастер «переезжает» в majority. Minority гасит свой PostgreSQL.

            После восстановления сети

            • Старый (или новый) LEADER снова шлёт LEADER_STATUS.

            • Узлы, которые были в minority и/или имели расходящийся LSN, увидят dual-leader или broken replication → сработают:

              • сравнение LSN + hostname;

              • demote_node + auto_rebuild (pg_rewind / basebackup).

            • Кластер снова сходится к одному мастеру.

            PS: пока все под себя не протестируешь, и не решишь что нужно тебе лично, и не внесешь пул реквест с улучшением, это все пока нужно только мне, не более
            пример: демон GFM завис, а PostgreSQL жив и был мастером
            а меня пока все устраивает, и патрони я надеюсь мне больше никогда не понадобится


  1. Farrux28
    24.08.2026 19:00
    #30362116

    RAM. Если питание вырубится, она просто исчезнет, не оставив мусора. Это дает бешеную скорость

    Если предположим это случилось с 1м узлом, то получается данные исчезнут? И даже после обратного включения узла, уже эти апдейты не будут существовать даже в вал?


    1. sqlmaster Автор
      24.08.2026 19:00
      #30362574

      Данные не пропадут: Postgres сохраняет WAL-логи на диске до подтверждения транзакции, поэтому при загрузке база восстановит всё из них.
      Если речь о gorgonad (меш-сети), то всё еще проще: она хранит в памяти только сигналы управления (кто лидер, логи событий), которые реплицируются при старте с другого живого узла, лимит на события задает кольцевой буфер в конфиге кластера меш ноды.
      При старте GFM выполняет функцию sync_role_with_db(), которая делает реальный запрос в базу: SELECT pg_is_in_recovery(). Только так менеджер может быть уверен, является ли узел Мастером или Репликой на данный момент.