Двунаправленная репликация таблицы в симметричном 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% конфликтов, но пропускаете несколько, то при возникновении конфликтов базы данных не будут идентичны на клиенте и сервере.