|
Я участововал в создании распределенного решения на другой системе. Не на SQL. И механизмы репликации самой СУБД никак не задействовались - намеренно. Не думаю, что безумно сложно реализовать её и на Аксапте, по крайней мере, в рамках ограниченных модулей. Общая схема такая:
- для базах выделяются раздельные диапазоны для кодов не RecId, а именно кодов. Поскольку средства репликации СУБД не используются, RecId не имеют значения - записи при репликации создаются с новыми RecId. Диапазоны выделяются тем, что каждая удаленная база имеет свой прядковый номер, "знает" его и вставляет его префиксом для каждой номерной серии - вообще для каждой.
- каждая удаленная база формирует очередь из созданных, модифицированных и удаленных записей. На основе этой очереди в момент сеанса репликации формируется пакет данных для передачи. Очередь не очищается, пока не придут подтверждения из другой базы об удачной репликации.
- пакет приходит в другую базу, записи встраиваются в неё (удаленны удаляются, измененные изменяются).
- Важным является тот момент, что таблицы БД заранее разделены на 2 типа: 1 - передаваемые при репликации и 2 - не передаваемые, а пересчитываемые в момент приема пакета (в Аксапте это была бы, например, InventSum).
- Для принятых записей формируется пакет подтверждений. Он отправляется обратно и удаляет очередь в первой базе - разумеется, только по тем записям, прием которых был подтвержден. Если пакет записей или пакет подтверждений был утерян, то конечно процесс повторяется - таким образом обеспечивается целостность.
Разумется, там есть еще нюансы. Но в целом ничего безумно сложного.
|