Обнаружение и разрешение конфликтов обновлений посредством очередей
Поскольку подписки, обновляемые посредством очередей, допускают изменения одних и тех же данных в различных местоположениях, при синхронизации данных у издателя могут возникать конфликты. Системой репликации обнаруживаются любые конфликты, возникающие при синхронизации изменений с издателем, которые затем разрешаются с помощью политики разрешения конфликтов, выбранной при создании публикации.
Процесс обнаружения и разрешения конфликтов может потребовать много времени и ресурсов, поэтому рекомендуется минимизировать количество конфликтов приложения, создавая секции данных таким образом, чтобы разные подписчики изменяли разные подмножества данных.
Обнаружение конфликтов
При создании публикации и включении обновления посредством очередей система репликации добавляет в базовую таблицу столбец 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: How to: Enable Updating Subscriptions for Transactional Publications (Replication Transact-SQL Programming)
Просмотр конфликтов данных
- SQL Server Management Studio: Как просмотреть конфликты данных для публикаций транзакций с подписками, обновляемыми посредством очередей (среда SQL Server Management Studio)
Побеждает издатель
Когда параметр разрешения конфликтов имеет значение «Побеждает издатель», согласованность транзакций поддерживается на основании данных издателя. Происходит откат конфликтной транзакции у инициировавшего ее подписчика.
Агент чтения очереди обнаруживает конфликт, после чего создаются компенсирующие команды, которые передаются подписчику путем внесения их в базу данных распространителя. Затем агент распространителя применяет компенсирующие команды в отношении подписчика, инициировавшего конфликтную транзакцию. Компенсирующие операции обновляют строки у подписчика для соответствия строкам у издателя.
До применения компенсирующих команд можно считать результаты транзакции, откат которой в конечном итоге будет выполнен на подписчике. Это эквивалентно недействительному результату чтения (чтению незафиксированного уровня изоляции). Компенсация последующих зависимых транзакций, которые могут произойти, отсутствует. Однако при этом соблюдаются границы транзакций? и все действия в пределах транзакции либо завершаются, либо, в случае конфликта, выполняется их откат.
Побеждает издатель, и подписка повторно инициализируется
Повторная инициализация подписчика с целью разрешения конфликтов поддерживает строгую согласованность транзакций на подписчике, но она может занимать много времени, если публикация содержит большое количество данных.
Когда агент чтения очереди обнаруживает конфликт, все остальные транзакции в очереди (включая конфликтные транзакции) отклоняются, а подписчик помечается для повторной инициализации. Следующий моментальный снимок, создаваемый для публикации, применяется агентом распространителя к подписчику.
Побеждает подписчик
Обнаружение конфликтов в соответствии с политикой «Побеждает подписчик» означает, что побеждает последняя транзакция подписчика, обновляющая издателя. В этом случае при обнаружении конфликта продолжает использоваться транзакция, отправленная подписчиком, а издатель обновляется. Эта политика подходит для приложений, в которых подобные изменения не нарушают целостность данных.
См. также
Основные понятия
Обновляемые подписки для репликации транзакций