Добрый день! Разрабатываю рукописную репликацию справочников.

Репликация односторонняя, т.е. база tgt должна следовать за базой src.
В базе tgt запись в справочники не происходит иначе, как чем через репликацию.

Стратегия принята примерно такая:

все пишущие транзакции в системе - snapshot.

имеется таблица


имеется набор триггеров, заносящих в неё запись при insert и update
(delete пока вовсе не обрабатывается, потом планирую сделать поле пометки, как в dbf).

id в ней - это суррогатный ключ, порождается генератором.

Для маленьких таблиц rec_id всегда = 0, для больших - rec_id = суррогатный ключ изменяемой записи.
Для таблиц, подчинённых большим - rec_id = значение FK ссылки на владельца.

За репликацию отвечает отдельное приложение, подключенное к обеим базам.
Периодически или по пинку от пользователя оно запускает репликацию, к-рая состоит в следующем:

1. стартуется одна транзакция в src и одна - в tgt (обе - snapshot)

2. Смотрим, есть ли в таблице rpl_edition базы src записи, которых нет в такой же таблице базы tgt.
Если есть, то берём всё множество таких записей и упорядочиваем его в порядке ссылки таблиц
(так, чтобы записи, на которую идут ссылки, появились до того, как записи, которые ссылаются).
Циклические и рекурсивные ссылки разрешаются тем, что таблица обрабатывается более одного раза,
но в первый раз поля, образующие цикл, остаются null-ами.
3. По каждой отличающейся записи в rpl_edition проводим соответствующую репликацию, т.е. берём данные
из какой-то таблицы в src и пишем в такую же таблицу в tgt.
4. Все такие же записи вставляются в rpl_edition базы tgt.
5. commit в обоих базах (в src мы ничего не писали)
6. в отдельной транзакции с коротким таймаутом, отдельным тредом стираем все совпадающие записи
в rpl_edition базы src. Если не стёрлось - откатываем её.
7. Повторение п.7 для базы tgt.
8. Отключение триггеров на реплицируемых таблицах: видимо, будет стоять развязка по пользователю, т.е., если пользователь= репликатор, то определённые триггеры отключаются (спасибо Ivan_Pisarevsky), хотя для начала хочу полениться
и сделать просто переменную контекста, которую устанавливаем и тем самым отключаем триггер.

Думал чуть ни неделю над этим алгоритмом. Вроде всё нормально, но покоя в душе нет.
Прошу осудить и кинуть тапком, сказав, какие грабли меня при этом ждут.

Ivan_Pisarevsky, изобретаю потихоньку... А как у вас?

Гаджимурадов Рустам, привычка укладываться в 8.3 :)

Может, dst было бы и правильнее, но уже поздно для данного о(б)суждения.

src может меняться в любой момент времени, отсюда и снапшот.

Я вообще хочу все перевести на снапшоты, ввиду моей
неспособности/лени проанализировать, как всё
будет работать с read committed - слишком много возможных
аномалий нужно предполагать на каждую строчку кода.

Ivan_Pisarevsky, я вне традиции, видимо :)
Если она где-то описана, положи в тапок ссылку
и кинь в меня им.
Что такое z-триггеры? Яндекс промолчал.

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

А как у тебя упорядочиваются скрипты? Пусть у нас есть таблица
со ссылкой на себя. За счёт чего запись А придёт в tgt раньше, чем ссылающаяся
на неё запись Б? Учитывается время вставки? А если придут с меньшим
интервалом, чем разрешение часов? Генератор?

Каков уровень изоляции транзакций? Бывают ли сбои из-за внешних ключей,
особенно на delete?

Ivan_Pisarevsky, вот тут и есть самое непонятное. Раз порядок стейтментов как-то определён и это не таймстамп, то значит генератор. Если генератор, то порядок следования апдейтов в репликации слабо связан с порядком старта и коммита транзакции, которая его создала. Если транзакция А стартовала до старта транзакции Б и финишировала до финиша транзакции Б, значит ли это, что она более ранняя? Если используется генератор, то запрос от транзакции Б может раньше пойти на репликацию, чем запрос от транзакции А. И получится, что транзакция Б - "раньше", чем А. Оттого я и спросил про таймстампы. Вроде из этого ничего страшного не следует, потому что есть ещё блокировка записей. Т.е., если здесь будет какие-то конфликтующие друг с другом изменения, одна из транзакций просто не будет закоммичена. Но я не могу сказать, что полностью уверен в надёжности.

Ivan_Pisarevsky, да не в дырках дело. Вот какой сценарий
может быть проблемным:

началась транзакция А, да призадумалась
началась транзакция Б (read committed)
транзакция Б запросила генератор и получила 1
транзакция А запросила генератор и получила 2
транзакция А вставила запись АА в таблицу data
транзакция А вставила в таблицу скриптов репликации ('insert into data запись АА ',2)
транзакция А завершилась
транзакция Б вставила запись ББ в таблицу data
-- где запись ББ ссылается на АА
транзакция Б вставила в таблицу скриптов репликации ('insert into data запись ББ',1),
транзакция Б завершилась

Просыпается мафия репликатор.
select * from таблица_скриптов order by id

По порядку она отправляет в другую базу сначала запись ББ, потом запись АА.
Запись ББ не вставляется, т.к. нарушение FK.

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

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

практика показывает, что ничего страшного не случается.
А вот это обнадёживает :)

NickDee, вариант с монопольной блокировкой базы или таблицы
мне не нравится.
Шавлюк Евгений, ваш вариант тоже не нравится из-за необходимости
лишних действий при б/р.

NickDee, в моей задаче вроде не предвидятся конфликты записей, т.к. база tgt не пишет в справочники. Поэтому для меня блокировка выглядит слишком уж тяжёлой ношей.

kdv, не совсем легко понять вас, но если я правильно понял, то вроде Dimitry Sibiryakov уже развенчал такой вариант.

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

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

Ivan_Pisarevsky, да уж поздно рыпаться - много сделал уже. Хотя на сайт Сибирякова заходил, ценник действительно демократичный. Сторонний продукт - всегда риск, что вдруг кастомизация окажется в чём-то недостаточной и начнёшь вокруг этого продукта плясать с бубном. Ну и другие причины, например, у нас есть уже свой сервер приложений, ну озадачим его ещё одним видом деятельности. Плюс к тому, я умею делать, чтобы метаданные для репликатора росли вместе со структурой базы. Плюс к тому, кастомный алгоритм назначения ид-ов. Плюс к тому, репликация должна идти не с нуля, а заменяет уже существующий алгоритм, который отчасти справляется с задачей, часть данных уже закачаны, и т.д., и т.п.

Я не буду создавать стейтменты в виде текста, буду раскладывать данные по полям, но в целом для меня самое важное то, что последовательность действий _можно_ передавать с одного сервера на другой и это работает. Это не было очевидно.

Всех с прошедшими!
Fr0sT-Brutal,

началась транзакция A
А:insert into data values (AA)
А:триггер data_after_insert
gen_id(g_replication,1)->1
insert into replication_script values ('insert into data values (AA)',1)


началась транзакция Б
Б:insert into data values (ББ)
Б:триггер data_after_insert
gen_id(g_replication,1)->2
insert into replication_script values ('insert into data values (ББ)',2)
Б:commit

просыпается репликатор, видит запись 2 и отправляет её в другую БД

А:commit
просыпается репликатор, видит запись 1 и отправляет её в другую БД

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

Fr0sT-Brutal, вроде бы и нельзя. Но я не понимаю, почему нельзя. Нету доказательства корректности этого алгоритма.
Во всяком случае, то, что пересекающиеся по времени транзакции могут попадать в репликатор в произвольном порядке,
вызывает определённую озабоченность. Остаётся только надеяться, что при уровне изоляции snapshot мы никогда не сошлёмся
на незакоммиченный инсерт, а благодаря блокировкам не сошлёмся на запись, которую удалила одновременная транзакция.