по ключам "граф репликация" и "граф синхронизация" ничего тут поиском навскидку не нашёл, поэтому вопрос к ALL.

постановка (хотелки, размыто).
есть некоторое количество однотипных (территориальных) БД, собирающих первичные данные.
часть из них , допустим региональные, как собирают данные сами, так и принимают данные от чисто "первичных" узлов,
часть из них, допустим верхне-региональные, собирают данные как с узлов нижнего уровня, так и узлов срденего.
как это всё реализовывать?
ну и есть какое-то количество подписчиков верхнего уровня, одинаковые по сумме подписок, но разные по собственным задачам.


допустим [мысль о реализации], данное всегда ложится в 2 таблицы -- собственно данное + событие данного.

допустим, событие данного потом накатывается на подписчика. (батчиками. и только тогда, когда подключимся, т.е. не "почти онлайн", а эпизодически). т.е. реально имеем событие некоего pkey, которое накатывается в такой же pkey на всех подписчиках [тогда, когда и если подписчики сумеют принять это событие].

Единственное что надо обеспечить -- непересекаемость областей pkey разных публикаторов. И эпизодическую видимость вдоль подписки.


до тех пор пока граф подписчиков не петляет (нет двух путей от первичного публикатора --- проблем в накатках событий особо не видно (есть теоретическая проблем порядка сообщений по коммитам, а не по стартам, но в каком-то приближении можно считать её не очень острой)


теперь допустим, какого-то публикатора захотели подписать 2 узла 2-го уровня, на которые (оба-2) подписан узел 3-го. а то и сам 3-й подписать на тот же первичный -- ибо он чаще виден 3-му, чем промежуточные. [узел спорного или совместного подчинения].
-- возникают коллизии как по событиям pkey-ев первичного узла, так и по порядкам их появления в разных очередях (собственно с первичного,или опосредованно -- с промежуточного).

первая попавшаяся идея -- проверять значение, и при совпадении полной записи коллизию игнорировать -- не совсем катит. более поздно может подключиться тот узел, который имеет более старую копию первичного данного -- при этом это надо как-то обоснованно опустить, не прерывая накатки прочих событий той же очереди. [но ошибки иного вида должны останавливать процесс -- как непредусмотренные]

т.ч. ищется формула"способ передачи таких (модифицируемых) сообщений о состоянии объекта p_key по несинхронизированному графу узлов с петлями, и задержками, с распределенными источниками, который бы гарантировал как разрешение коллизий [с ассинхронной доставкой версий], так и распространение [только] последней версии сообщений о состоянии объектов[а] p_key"

...отличающийся тем, что ....
с учетом того, что первичное событие заданного p-key всегда генеририруется (должно генерироваться) одним и тем же узлом (а вторичные события -- вдоль пути синхронизации -- д.б. вызваны всегда первичными)

--кто-то в курсе, где собаке порыться ?
какие абстракции тут модны (кроме "публикатор/подписчик/сообщение/очередь") ?


ну и вообще -- идея находюся ?

Кот Матроскинэттатеперь допустим, какого-то публикатора захотели подписать 2 узла 2-го уровня, на которые (оба-2) подписан узел 3-го. а то и сам 3-й подписать на тот же первичный -- ибо он чаще виден 3-му, чем промежуточные. [узел спорного или совместного подчинения].
-- возникают коллизии как по событиям pkey-ев первичного узла, так и по порядкам их появления в разных очередях (собственно с первичного,или опосредованно -- с промежуточного).

Ну и что? Надо сделать механизм их разрешения. Каков он будет - зависит, очевидно, от задачи (например, можно расставить узлам приоритеты, и в случае коллизии всегда отбрасывать версию из источника, имеющего меньший приоритет. Или еще 100500 вариантов).
Вопрос-то в чем?вопрос таки в том, "что именно я должен заранее сделать (?)", чтобы не лажать лажовой системой лажовых приоритетов, не имеющих отношения к реальному историческому порядку событий -- а поиметь систему разрешения коллизий событий таки не "отМатроскин", а с учётом этого реального порядка.

т.ч. гражданин, не делали, не думали, не задумались сейчас --- идите , куйте, не задерживайтесь

кажется, если в само данное мы будем писать ид ноды--фиксатора, и ид события [на этой ноде, этой строки] данного -- и распространять этот маркер вдоль по графу (когда его, маркера т.е., нет -- мы первичные -- заполняем маркер в момент записи события, когда есть в пришедшем сообщении (в поле "тело события" -- передаём в данное как есть) -- то проблема решается.

т.е. маркер первичного события кладем в само данное. Т.е. так обслуживается всё, кроме событий "DELETE". у "DELETE" нет "самого данного", но есть его событие. Передаться исключительно через данное не получается.
тут пока не понял, нужно ли что-то.
(хотя есть старый хак с двойной оберткой -- подписываться на "события" а не на данные -- тогда у события DELETE появляется сквозное распространяемое тело).


ps кошара, иди, куй
в "работе" вон продолжай языком полоскать

pps пока писал - сибиряков написал про маркеры. и это радует. -- "не лисапет"