Queued Updating Conflict Detection and Resolution
Поскольку подписки, обновляемые посредством очередей, допускают изменения одних и тех же данных в различных местоположениях, при синхронизации данных у издателя могут возникать конфликты. Системой репликации обнаруживаются любые конфликты, возникающие при синхронизации изменений с издателем, которые затем разрешаются с помощью политики разрешения конфликтов, выбранной при создании публикации. Могут возникнуть следующие конфликты.
Конфликты обновления и вставки. Этот конфликт происходит, когда одни и те же данные изменяются в разных местах. Одно изменение вступает в силу, а другое нет. При этом говорят о выигрыше одного изменения относительно другого.
Конфликты при удалении данных. Данный конфликт происходит, когда одна и та же строка удаляется в одном месте и изменяется в другом.
Процесс обнаружения и разрешения конфликтов может потребовать много времени и ресурсов, поэтому рекомендуется минимизировать количество конфликтов приложения, создавая секции данных таким образом, чтобы разные подписчики изменяли разные подмножества данных.
Обнаружение конфликтов
При создании публикации и включении обновления посредством очередей система репликации добавляет в базовую таблицу столбец uniqueidentifier (msrepl_tran_version) со значением по умолчанию newid() . Когда опубликованные данные изменяются у издателя или подписчика, строка получает новый глобально уникальный идентификатор (GUID), указывающий на существование новой версии строки. Этот столбец используется агентом чтения очереди во время синхронизации для обнаружения конфликтов.
Транзакция в очереди содержит и старое, и новое значение версии строки. При применении транзакции у издателя осуществляется сравнение значений GUID из транзакции и значения GUID в публикации. Если старое значение GUID, хранимое в транзакции, совпадает со значением GUID в публикации, то публикация обновляется, и строке назначается новое значение GUID, созданное подписчиком. Благодаря обновлению публикации значением GUID из транзакции обеспечивается совпадение версий строк в публикации и в транзакции.
Если старое значение GUID, хранимое в транзакции, не совпадает со значением GUID в публикации, обнаруживается конфликт. Новое значение идентификатора GUID в публикации указывает на существование двух разных версий строки: одной в транзакции, предоставленной подписчиком, и более новой версии, существующей у издателя. Это означает, что другой подписчик или издатель обновил ту же самую строку в публикации перед тем, как была синхронизирована данная транзакция подписчика.
В отличие от репликации слиянием столбец GUID используется не для идентификации самой строки, а для проверки факта ее изменения.
Разрешение конфликтов
При создании публикации, обновляемой посредством очередей, выбирается сопоставитель конфликтов для использования при обнаружении конфликтов. Сопоставитель конфликтов определяет, как агент чтения очереди обрабатывает разные версии одной и той же строки, обнаруженные при синхронизации. Политику устранения конфликтов можно изменить после создания публикации до тех пор, пока отсутствуют подписки на публикацию. У сопоставителя конфликтов имеются следующие варианты выбора:
Побеждает издатель (по умолчанию)
Побеждает издатель, и подписка повторно инициализируется
Побеждает подписчик
Записи о конфликтах сохраняются и их можно просмотреть при помощи средства просмотра конфликтов.
Установка политики устранения конфликтов обновления посредством очередей
SQL Server Management Studio: настройка параметров разрешения конфликтов при обновлении в очереди (SQL Server Management Studio)
Программирование репликации на Transact-SQL: Enable Updating Subscriptions for Transactional Publications
Просмотр конфликтов данных
- SQL Server Management Studio: просмотр конфликтов данных для публикаций транзакций (SQL Server Management Studio)
Побеждает издатель
Когда параметр устранения конфликтов имеет значение «Побеждает издатель», согласованность транзакций поддерживается на основании данных издателя. Происходит откат конфликтной транзакции у инициировавшего ее подписчика.
Агент чтения очереди обнаруживает конфликт, после чего создаются компенсирующие команды, которые передаются подписчику путем внесения их в базу данных распространителя. Затем агент распространителя применяет компенсирующие команды в отношении подписчика, инициировавшего конфликтную транзакцию. Компенсирующие операции обновляют строки у подписчика для соответствия строкам у издателя.
До применения компенсирующих команд можно считать результаты транзакции, откат которой в конечном итоге будет выполнен на подписчике. Это эквивалентно «грязному» чтению (уровень изоляции незафиксированной операции чтения). Компенсация последующих зависимых транзакций, которые могут произойти, отсутствует. Однако при этом соблюдаются границы транзакций, и все действия в пределах транзакции либо завершаются, либо, в случае конфликта, выполняется их откат.
Побеждает издатель, и подписка повторно инициализируется
Повторная инициализация подписчика с целью разрешения конфликтов поддерживает строгую согласованность транзакций на подписчике, но она может занимать много времени, если публикация содержит большое количество данных.
Когда агент чтения очереди обнаруживает конфликт, все остальные транзакции в очереди (включая конфликтные транзакции) отклоняются, а подписчик помечается для повторной инициализации. Следующий моментальный снимок, создаваемый для публикации, применяется агентом распространителя к подписчику.
Побеждает подписчик
Обнаружение конфликтов в соответствии с политикой «Побеждает подписчик» означает, что побеждает последняя транзакция подписчика, обновляющая издателя. В этом случае при обнаружении конфликта продолжает использоваться транзакция, отправленная подписчиком, а издатель обновляется. Эта политика подходит для приложений, в которых подобные изменения не нарушают целостность данных.