Как настроить двунаправленную репликацию на одной таблице в симметричном DS?

Question

Я установил и настроил программное обеспечение для репликации базы данных с http://www.symmetricds.org/ на клиенте и сервере. Я следовал инструкциям по настройке репликации примера, и все работает так, как рекламируется.

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

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

Где инструкции по созданию двунаправленной репликации базы данных в симметричных СД? Примером по умолчанию, который они предоставляют, являются насосы однонаправленной репликации

Моя система:

Client: Fedora 17 Linux with postgresql
Server: Windows 8 with mysql

Моя самонадеянная попытка двунаправленных насосов провалилась:

Триггер sym_trigger_router - это место, где вы определяете направление прокачки данных. Я создаю насос в обоих направлениях. Но это создает проблему с конфликтами с применением ключа. Если вставка, обновление или удаление выполняются в одно и то же время для одного и того же ключа, базе данных придется предпринять корректирующие действия для восстановления работоспособности.

Есть ли инструкции, как это сделать, или кто-нибудь сделал это?

Answer 1

Двунаправленная репликация таблицы в симметричном DS

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

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

У механизма синхронизации есть выбор:

1.  Take the last insert/update by timestamp and destroy the request that came 
    first.  This is undesirable because the first person thought they committed,
    successfully when in reality their transaction was erased without anyone's 
    consent.

2.  Reject both rows, if I can't make everyone happy, I'm not letting anything
    through, and log the conflict to an external table to be dealt with later.
    The two users who thought they submitted data will find their transaction
    in a queue.

3.  Merge the rows, take a little from one, and a little from the other, and 
    create a hybrid row.  Or take one or the other based on some priority system
    or based on how filled out it is.

Это всего лишь один пример конфликта. Существуют сотни возможных обстоятельств, при которых может возникнуть конфликт, который вы должны спланировать.

Сотни возможных ситуаций, в которых может возникнуть конфликт, должны иметь корректирующее действие, определенное в таблице конфигурации: sym_conflict .

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

Количество потенциальных конфликтов зависит от конфигурации и ограничений таблицы базы данных. По мере того, как вы добавляете в свою таблицу условия и ограничения, количество потенциальных конфликтов увеличивается в геометрической прогрессии. Если у вас есть уникальные ключи, вам нужно подготовиться к конфликтам уникальных ключей и определить решения. Если у вас есть первичные / внешние ключи в других таблицах, вам нужно разрешение конфликтов для них. Если вы получаете 90% конфликтов, но пропускаете несколько, то при возникновении конфликтов базы данных не будут идентичны на клиенте и сервере.