Там придётся к этой системе ещё и мониторами обмазаться, причём ты обязательно проебешься с десериализацией пида

Вот такая ситуация
Есть две ноды, на одной запущен user1, на другой user2
Ноды теряют связь между собой.
По твоей логике на каждой ноде тогда должен быть и user1 и user2?

В целой системе должен быть только один user1  и один user2

А как части системы, которые не могут между собой общаться, решат у кого какой user ?

Я полагаю это должно решаться таймстампами и постоянным пингом процесса с базой данных.

Правильный ответ — никак

если процесс отвалился он не пингует в базу. В базе данных процесс становится свободным.

Его забирает другая нода.

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

Но если она одна, тогда каждая нода может знать в какой из частей она

Да, это классическая CP система. Тот у кого база, тот и правит

Фишка только в том, что rdb это самый худший инструмент для таких приколов

Но всё же лучше, чем тащить что-то ещё в какой-то маленький проект
Лучше всего, конечно же, было бы затащить redis с одним мастером

И я все ещё не понимаю, как не удаляя записи можно вообще хоть как-то управлять этим хозяйством

Таймстемподрочка можно, но это какой-то тоже не элегантный способ

Да, насчёт реализации в pgsql надо подумать поплотнее

в целом да, но сам дрочка достаточно медленная будет, не думаю это будет сильно грузить систему хз на счет постгреса но если Redis или Etcd должно нормально работать.

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

Да впринципе, можно легко это решить руками эрланга. Выбирать лидера при инициализации системы. Лидер держит какой-нибудь Horde.Supervisor у себя и всё

В идеале должен быть сервис, который держит дуплекс tcp соединение с нодой и получает от неё диффы по статусам KV. В случае разрыва коннекта все ключи, переданные через это соединение идёт в мусорку.

В случае, если другое соединение пытается совершить операции с ключом, «забитым» другим соединением - в самом простом случае - TCP коннект просто рвёт сам сервис, а потом применяет все правила.


Соответственно в BEAM один генсервер может все это дело трекать. Если нода крешнется - все ее ключи исчезнут. Если сервис порвёт соединение - то сам генсервер у себя удаляет все процессы, переконнекчивается и начинает все заново