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

MySQL made its money from the "enterprise" version (identical to the "community" version plus some management software). The hook was that you couldn't buy support from MySQL without an enterprise license. MySQL support was absolutely excellent; people were will to pay big bucks to get it. And helping things was the fact that MySQL replication was so delicate that nobody in their right mind would run it without access to expert hand holding when things started to blow up.

Из двух зол

При реализации механизма репликации баз данных приходится выбирать из двух зол: либо максимальная свобода пользователя и неизбежные конфликты при слиянии данных, либо ограничение — что, где и когда можно изменять.

Какое из двух зол будет меньшим зависит от требований клиента и внутренней архитектуры приложения. В случае с Гедымином, механизм фиксации складского движения чрезвычайно чуствителен к очередности обработки документов и некоторые типы конфликтов принципиально не могут быть разрешены "малой кровью". Остается путь с блокировками, когда в один момент времени данные одного типа могут редактироваться только на одной базе.

Доказательство от противного

Если бы полная мультинаправленная асинхронная неограниченная дельта репликация была возможна, то мир баз данных выглядел бы совсем иначе. Возьмем наших клиентов. Даже у крупных — размер БД измеряется десятками Гб, в то время как винчестеры современных настольных компьютеров имеют емкость до Тб, а то и более. В схеме с репликацией оператор работал бы на автономной копии БД, а когда возникала необходимость, скидывал бы дельту на центральную базу и загружал себе изменения, сделанные другими пользователями.

Плюсы очевидны:

• устойчивость к потере данных (никакой RAID не сравнится)
• возможность работать без подключения к сети
  
• распределение нагрузки на все компьютеры
  

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

Параллельными курсами

В статье про организацию репликации читаем:

Для унификации желательно, чтобы в каждой таблице, включенной в процесс синхронизации был суррогатный первичный ключ (ID) - обычно INTEGER. Впрочем, чаще всего так и есть. Как же мы можем обеспечить уникальную идентификацию записей.
...
Можно сделать первичным ключем строку спецального формата, например XXXX-YYYY-ZZZZZZZZ, где XXXX - это идентификатор базы данных, где запись была создана впервые, YYYY - идентификатор таблицы, ZZZZZZZZ - идентификатор записи внутри конкретной таблицы конкретной БД.

Практически наш RUID, только что нам нет смысла хранить ID таблицы, так как идентификатор записи уникален в пределах одной базы данных. Наше отличие — для хранения RUID используется отдельная таблица. Была идея хранить RUID непосредственно в каждой таблице, но от нее отказались по соображениям экономии места. Не каждая запись нуждается в получении загранпаспорта.

Там же:

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

Аналогичная идея была в Гедымине. Для смещения идентификаторов в каждой базе планировалось применять свое значение генератора gd_g_offset. Типичный код триггера на присвоение идентификатора записи:

CREATE TRIGGER gd_bi_command FOR gd_command
  BEFORE INSERT
  POSITION 0
AS
BEGIN
  IF (NEW.ID IS NULL) THEN
  NEW.ID = GEN_ID(gd_g_unique, 1) + GEN_ID(gd_g_offset, 0);
END

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

PS: Перенос прикладных настроек — это по сути односторонняя репликация в урезанном виде.

PPS: Подборка материалов по репликации (синхронизации) БД.