Dimitry SibiryakovЭто, конечно, хорошо, но записи просто так не исчезают, их кто-то удалил
Нет, вот это неправда :) Удаление записи у меня в обязательном порядке разъезжалось по всем серверам, даже по тем, где такой записи никогда не было - как раз для предотвращения всякого рода "призраков прошлого". Вариант, когда с сервера А на сервер Б послали запись 1, а в это время на сервере Б удалили запись 2, на которую запись 1 ссылается - исчезающе редкая экзотика. Просто потому, что по бизнесу записи вообще редко удаляют, а если удаляют - то перед этим переводят в статус, когда ссылки на них исключены.

На практике вышеописанная логика перезапроса в 100% случаев срабатывала в следующей ситуации: запись 1 по правилам репликации доставили на сервера 1, 2 и 3 (и не доставили на 4, 5 и 6), на сервере 3 ей создали деталь (запись 2), и та должна быть доставлена на сервера 1, 2, 3 и 5. Вот в этом случае 5-й сервер запрашивал себе копию первой записи.

Dimitry SibiryakovЧто делать на ноде, где к удаляемой записи есть детали и возникает ошибка нарушения внешнего ключа при попытке её удаления?
Ничего :) У меня это просто легло бы в таблицу конфликтов репликации, а всё остальное спокойно поехало бы дальше. Наутро, увидев такое безобразие, я намылил бы шею автору такого замечательного конфликта и научил бы его подходящему к ситуации способу исключения возможности таких ситуаций.

Dimitry SibiryakovА что с уникальными ключами? Что и у кого запрашивать, когда, грубо говоря, в таблицу фамилий на разных нодах добавили двух Ивановых?
По ситуации было несколько решений. Само частое - на нодах создавалась заявка на добавление Иванова , на которую ограничения уникальности не распространялись. Подтверждением же заявок занимался либо процесс, работающий на центральном сервере, либо конкретный ответственный человек, который в каждый момент времени работал только на одной ноде.

Dimitry SibiryakovСамый забавный вопрос: что делать если на одной ноде поле в записи изменили с 1 на 2, а на другой - с 1 на 3?
Это не забавный вопрос, а скорее околотеоретическая ситуация. Она противоречит логике бизнеса, согласно которой у записи есть права доступа, и никакой левый перец просто так не может и не должен изменять поле. Её проще объяснить бескомпьютерной аналогией: если дело Иванова лежит в шкафу у Марь Иванны, никакой чувак из другого города не может просто так открыть его и черкнуть там пару строк. От того, что "шкаф" меняется на "сервер", логика доступа не меняется, дело Иванова по-прежнему может редактировать либо Марь Иванна, либо кто-то, кому она его отдала.

Да, в некоторых случаях предусматривали такие режимы работы. Например, это могло выглядеть так. Марь Иванна поменяла поле с 1 на 2. В это время её начальник, находясь в командировке в другом городе, взял запись себе и поменял поле с 1 на 3. В этом случае реплика Марь Иванны, добравшись до сервера начальника, отпала по причине "запись уже не Марь Иванны" и упала в ошибки репликации. Тем временем, от её начальника на сервер Марь Иванны приехали реплики сначала "беру запись себе", потом "меняю поле на 3". В результате запись стала везде "начальственной". Ну а я с утра, посмотрев на это безобразие, убедился, что всё в порядке и добавил настройку, согласно которой такая ситуация ошибкой не считается и рапортовать о ней незачем.

PgSQLanonymous3Когда речь идёт о multi-master в СУБД, чаще всего имеется в виду ACID реализация, а не наколенные не-ACID поделки, примерно так.
Когда речь идёт о программных продуктах, чаще всего имеется в виду то, что они должны работать и решать задачи бизнеса, а не высокомерно курить в сторонке со словами "Нам это не по плечу". Не по плечу - нахрен с пляжа, вот и весь разговор.

PgSQLanonymous3как уже теоретически доказано
И это один из тех случаев, когда теоретиков можно и нужно обозвать теоретиками. Они пытаются решать задачу, которая не имеет отношения к практике - и доказывают, что её решить невозможно. Если же сосредоточиться на тех требованиях, которые идут от практики - где-то сужающих задачу, где-то дающих большую свободу и т. п. - оказывается, что они вполне выполнимы.

PgSQLanonymous3А упорной реальности как-то всё равно, чего там "хочет бизнес".
Уважаемый, у Вас упоротое представление о реальности.