Распознавание и разрешение конфликтов в логических записях
В разделе рассматриваются различные комбинации подходов к распознаванию конфликтов и разрешению конфликтов, возможные при использовании логических записей. В репликации слиянием возникает конфликт, когда изменение одних и тех же данных производится более чем одним узлом, или же в репликации слиянием возникают определенные типы ошибок, такие как нарушение ограничений, когда изменяется репликация. Дополнительные сведения о распознавании и разрешении конфликтов см. в разделе Расширенное обнаружение и разрешение конфликтов репликации слиянием.
Указание уровня отслеживания и разрешения конфликтов для статьи
Microsoft Среда SQL Server Management Studio: Как указать уровень отслеживания и разрешения конфликтов для статей публикаций слиянием (среда SQL Server Management Studio)
Программирование репликации на языке Transact-SQL: Как указать уровень отслеживания и разрешения конфликтов для статей публикаций слиянием (программирование репликации на языке Transact-SQL)
Обнаружение конфликтов
Способ обнаружения конфликтов в логических записях определяется двумя свойствами статьи: column_tracking и logical_record_level_conflict_detection. SQL Server 2005 и более поздние версии также поддерживают логическое обнаружение на уровне записей. Дополнительные сведения об отслеживании на уровне столбцов или строк см. в подразделе «Уровень отслеживания» раздела Способы обнаружения и разрешения конфликтов, используемые при репликации слиянием.
Значением свойства статьи logical_record_level_conflict_detection может быть TRUE или FALSE. Значение должно быть задано только для родительской статьи верхнего уровня. Кроме того, его должны игнорировать все дочерние статьи. Если значение этого параметра FALSE, репликация слиянием обнаруживает конфликты, как в предыдущих версиях SQL Server, основываясь исключительно на значениях свойства column_tracking для статьи. Если значение этого параметра TRUE, репликация слиянием игнорирует значение свойства column_tracking для статьи и определяет конфликт, если где-либо в логической записи были сделаны изменения. В качестве примера рассмотрен сценарий:
.gif "Логическая запись из трех таблиц со значениями")
Конфликт обнаруживается, если два пользователя изменяют любые значения логической записи Customer2 в таблицах Customers, Orders, или OrderItems. В этом примере учитываются изменения, сделанные посредством инструкции UPDATE, но конфликт может быть также обнаружен, если изменения сделаны с помощью инструкций INSERT или DELETE.
Разрешение конфликтов
По умолчанию в репликациях слиянием для разрешения конфликтов используется логика, основанная на приоритетах. Если изменения, приводящие к конфликту, сделаны в базах данных двух подписчиков, предпочтение отдается изменениям подписчика с высшим приоритетом подписки; в случае одинаковых приоритетов побеждает подписчик, чьи изменения достигли издателя раньше. При обнаружении конфликтов на уровне строк или столбцов данные из строки победившего участника записываются поверх данных проигравшей базы данных.
Значением свойства статьи logical_record_level_conflict_resolution может быть TRUE или FALSE. Значение должно быть задано только для родительской статьи верхнего уровня. Кроме того, его должны игнорировать все дочерние статьи. При значении TRUE значение выигравшей логической записи записывается поверх проигравшей логической записи. При значении параметра FALSE, отдельные выигравшие строки могут быть взяты из различных подписчиков и издателей. Например, подписчик А может выиграть конфликт по строке из таблицы Orders, а подписчик В выигрывает по соответствующей строке из таблицы OrderItems table. Результатом будет логическая запись, содержащая данные из строки Orders подписчика А и строки OrderItems подписчика В.
Взаимодействие настроек обнаружения и разрешения конфликтов
Исходы конфликтов зависят от взаимодействия настроек обнаружения и разрешения конфликтов. В примере ниже предполагается использование разрешение конфликта на основе приоритетов. При использовании логических записей, возможны следующие варианты.
Обнаружение на уровне строк или столбцов, разрешение на уровне строк.
Обнаружение на уровне столбцов, разрешение на уровне логических записей.
Обнаружение на уровне строк, разрешение на уровне логических записей.
Обнаружение на уровне логических записей, разрешение на уровне логических записей.
Обнаружение на уровне строк или столбцов, разрешение на уровне строк
В этом примере публикация настраивается с помощью:
параметр column_tracking принимает значения TRUE или FALSE;
параметр logical_record_level_conflict_detection имеет значение FALSE;
параметр logical_record_level_conflict_resolution имеет значение FALSE.
В этом случае обнаружение конфликтов осуществляется на уровне строк или столбцов, а разрешение — на уровне строк. С помощью этих настроек используется преимущество, когда все изменения в логической записи реплицируются как одно целое, но без обнаружения или разрешения конфликта на уровне логических записей.
Обнаружение на уровне столбцов, разрешение на уровне логических записей
В этом примере публикация настраивается с помощью:
параметр column_tracking имеет значение TRUE;
параметр logical_record_level_conflict_detection имеет значение FALSE;
параметр logical_record_level_conflict_resolution имеет значение TRUE.
Издатель и подписчик начинают работать с одним и тем же набором данных, логическая запись определяется между таблицами orders и customers. Издатель изменяет столбец custcol1 в таблице customers, а так же ordercol1 в таблице orders. Подписчик изменяет custcol1 в той же самой строке таблицы customers и столбец ordercol2 в той же строке таблицы orders. Изменения одного и того же столбца в таблице customer приводят к конфликту, но изменения таблицы orders к конфликту не приводят.
Поскольку разрешение конфликтов производится на уровне логических записей, выигравшими изменениями, сделанными издателем, заменяются изменения, сделанные в таблицах подписчика во время обработки репликации.
.gif "Последовательность таблиц, показывающая изменения связанных строк")
Обнаружение на уровне строк, разрешение на уровне логических записей
В этом примере публикация настраивается с помощью:
параметр column_tracking имеет значение FALSE;
параметр logical_record_level_conflict_detection имеет значение FALSE;
параметр logical_record_level_conflict_resolution имеет значение TRUE.
Издатель и подписчик запускаются с одинаковым набором данных. Издатель изменяет столбец custcol1 в таблице пользователи. Подписчик изменяет столбец custcol2 в таблице customers, а так же ordercol2 в таблице orders. Изменения одной и той же строки в таблице customers приводят к конфликту, но изменения подписчиком таблицы orders к конфликту не приводят.
Поскольку разрешение конфликтов производится на уровне логических записей, во время синхронизации изменения, сделанные в таблицах подписчика, заменяются выигравшими изменениями, сделанными издателем.
.gif "Последовательность таблиц, показывающая изменения связанных строк")
Обнаружение на уровне логических записей, разрешение на уровне логических записей
В этом примере публикация настраивается с помощью:
параметр logical_record_level_conflict_detection имеет значение TRUE;
параметр logical_record_level_conflict_resolution имеет значение TRUE.
Издатель и подписчик запускаются с одинаковым набором данных. Издатель изменяет столбец custcol1 в таблице пользователи. Подписчик изменяет столбец ordercol1 в таблице orders. Изменения не относятся к одной и той же строке или одним и тем же столбцам, но поскольку изменения произошли в одной и той же логической записи для custid=1, они распознаны как конфликт на уровне логической записи.
Поскольку разрешение конфликтов производится также на уровне логических записей, во время синхронизации изменения, сделанные в таблицах подписчика, заменяются выигравшими изменениями, сделанными издателем.
.gif "Последовательность таблиц, показывающая изменения связанных строк")