А чем лучше всего сделать глобальный лок, если много нодов,

до сотни?
ну то есть мне надо, чтобы некоторые операции с объектом не происходили одновременно.
перемещение между нодами, например.
сами объекты внешние - это большие файлы
можно писать в постгрес и лочить запись, но я подумал, мож процесс поднять или флажок в регистре или ещё чего

Есть https://www.erlang.org/doc/apps/kernel/global.html#set_lock/1. Ему с целом пофиг на количество нод, влияет только латенси между ними. Лучше всего просто сделать большой хэшринг на кластер, где есть один процесс на весь кластер, который держит файл, и пусть всё общение с файлом идёт через него

ы, интересно

Это надо тщательно тестировать на нетсплитах. Я делал уникальный по кластеру процесс через global. Изолированная нода запускает свой такой процесс, а при включении её в кластер решение, какой из процессов будет жить дальше, блокировало вообще всё до полного перезапуска.

оччень интересно, попробую воспроизвести

почему у многих такое непреодолимое желание писать что-нибудь в постгрес?

https://hexdocs.pm/individual/readme.html Посмотри, я делал пару лет назад

Это база по-умолчанию, которая используется всегда, когда не нужно распределённое хранилище. И даже когда нужно, всё равно используется )

Делал похожий тест на 26 эрланге. Цель была выяснить как поведет себя global при подключении новых нод и/или соединении двух кластеров как одинакового, так и разного размера. Сразу скажу, вывод надо перепроверить, потому что деталей не помню. Но получалось так, что при наличии зарегистрированного под одним именем в global в соединяемы кластерах процесса, при коннекте эрланг уронит процесс в меньшем по размеру кластере, а при равенстве размеров, уронит процесс в инициаторе коннекта (что в общем то логично, ты вызвал коннект, ты и обрабатывай проблему). Но ещё раз повторю, надо перепроверить вывод

у меня данные очень старые (лет 9 назад занимался этим), и там механизм консенсуса вставал колом — ноды бесконечно пересылали друг другу какие-то сообщения, чтобы договориться, чьи данные правильные. Кажется, это всё было до того, как какой-либо код мог принять решение, который из процессов убить.

Тогда понятно, потому что global чинили кажется в 25-м эрланге

Зависит от того как процесс запускается. Если под супервизором, то в каждом компоненте будет запущен свой процесс. Если без супервизора, то будет один. > решение, какой из процессов будет жить дальше, блокировало вообще всё до полного перезапуска Не вообще всё, а общение с процессами, а блокировка длится столько же, сколько и лок. Только там ещё коллбеки трансферные рассылаются

Размеры кластера никак не влияют на процесс, который умрёт. Там выбирается считай что рандомный Three predefined resolve functions exist: [`random_exit_name/3`](`random_exit_name/3`), [`random_notify_name/3`](`random_notify_name/3`), and [`notify_all_name/3`](`notify_all_name/3`). If no `Resolve` function is defined, `random_exit_name` is used. This means that one of the two registered processes is selected as correct while the other is killed. random_exit_name(Name, Pid, Pid2) -> {Min, Max} = minmax(Pid, Pid2), logger:log(info, "global: Name conflict terminating ~tw\n", [{Name, Max}]), exit(Max, kill), Min.

Там механизма консенсуса нет, есть multi_call по всем global процессам в кластере. Если кто-то не отвечает на multi_call, то операция падает

Вы можете выбрать стратегию из имеющихся или дать свой коллбэк.

Ок, я не вникал )