GFM: децентрализованная альтернатива Patroni и etcd для PostgreSQL на базе P2P-меша с In-Memory управлением

[sha256man]

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

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

[sqlmaster]

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

[sha256man]

А можно прокомментить четыре замечания 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.

[sqlmaster]

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

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

[sqlmaster]

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

[sqlmaster]

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

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

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