Обновляемые подписки для репликации транзакций

Область применения: SQL Server

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

• Немедленное обновление. Для обновления данных на подписчике должны быть подключены и издатель, и подписчик.

• Отложенное обновление. Для обновления данных на подписчике подключение издателя и подписчика не требуется. Обновления могут быть выполнены в режиме «вне сети» работы подписчика или издателя.

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

Если создается публикация транзакций с помощью обновляемых подписок в мастере создания публикаций, активизируется как немедленное обновление, так и отложенное обновление. Если создается публикация с помощью хранимых процедур, можно включить один или оба режима обновления. Когда создается подписка на публикацию, указывается используемый режим обновления. В случае необходимости можно переключать режимы обновления. Дополнительные сведения см. в следующем разделе «Переключение режимов обновления».

Включение обновляемых подписок для публикаций транзакций — Enable Updating Subscriptions for Transactional Publications

Создание обновляемых подписок для публикаций транзакций описано в этой статье для среды Management Studio.

Переключение режимов обновления

При применении обновляемых подписок можно указать, что подписка должна использовать один режим обновления, а затем можно переключиться на другой режим обновления, если это необходимо для приложения. Например, можно указать, что подписка должна использовать немедленное обновление, а затем переключиться на отложенное обновление, если ошибка системы привела к потере сетевого подключения.

Если переключитесь с немедленного обновления на отложенное обновление, то вам не удастся переключиться обратно на немедленное обновление, пока подписчик и издатель не подключатся, а агент чтения очереди не применит все сообщения, находящиеся в очереди, к издателю.

Переключение режимов обновления

Для переключения между режимами обновления необходимо разрешить оба режима обновления для публикации и подписки, а затем можно переключаться между режимами по мере необходимости. Дополнительные сведения см. в разделе
Переключение между режимами обновления для обновляемой подписки на публикацию транзакций

Вопросы использования обновляемых подписок

• После активизации для публикации обновляемых подписок или очереди обновляемых подписок данный параметр нельзя отключить для публикации (несмотря на то, что для подписок этот параметр не нужен). Чтобы отключить параметр, публикацию следует удалить и создать новую публикацию.

• Повторная публикация данных не поддерживается.

• Репликация добавляет столбец msrepl_tran_version в публикуемые таблицы для отслеживания. Из-за этого дополнительного столбца все инструкции INSERT должны содержать список столбцов.

• Для внесения изменений схемы в таблицу публикации, поддерживающей обновляемые подписки, необходимо остановить все действия в этой таблице на издателе и подписчиках, а отложенные изменения данных должны быть распространены на все узлы до внесения каких-либо изменений схемы. Это гарантирует отсутствие конфликтов невыполненных транзакций с отложенным изменением схемы. После распространения изменений схемы на все узлы можно возобновить действия в опубликованных таблицах. Дополнительные сведения см. в статье Заморозить топологию репликации (программирование репликации на языке Transact-SQL).

• Если планируется переключаться между режимами обновления, агент чтения очереди должен быть запущен, по крайней мере, один раз после инициализации подписки (по умолчанию агент чтения очереди работает непрерывно).

• Если база данных подписчика секционирована горизонтально и в секции есть строки, существующие на подписчике, но отсутствующие на издателе, подписчик не сможет обновить строки, существовавшие ранее. При попытке обновить эти строки возвращается ошибка. Данные строки должны быть удалены из таблицы и затем добавлены на издателе.

• Репликация транзакций с обновляемой очередью подписчиков может выполняться медленно, если используются уникальные фильтруемые индексы. Если возникнет конфликт для статьи, имеющей уникальные отфильтрованные индексы, то разрешение конфликта может привести к ненужному удалению и вставке тех строк, которые не входят в уникальный отфильтрованный индекс.

Обновления на подписчике

• Обновления на подписчике распространяются на издатель, даже если срок подписки истек или подписка неактивна. Убедитесь, что все такие подписки либо удалены, либо инициализированы повторно.

• Если используются столбцы TIMESTAMP или IDENTITY и они реплицируются как их базовые типы данных, значения в этих столбцах не должны обновляться на подписчике.

• Подписчики не могут обновлять или вставлять значения text, ntext или image , поскольку невозможно выполнить считывание из вставленных или удаленных таблиц внутри триггеров, отслеживающих изменения репликации. Аналогично подписчики не могут обновлять или вставлять значения text или image с помощью WRITETEXT или UPDATETEXT , поскольку данные перезаписываются издателем. Вместо этого можно секционировать столбцы text и image в отдельную таблицу и изменить две таблицы в пределах транзакции.

  Чтобы обновить большие объекты на подписчике, используйте типы данных varchar(max), nvarchar(max)и varbinary(max) вместо типов данных text, ntextи image соответственно.

• Обновления уникальных ключей (включая первичные ключи), создающие дубликаты (например, обновление вида UPDATE <column> SET <column> =<column>+1 ), не допускаются и будут отклонены из-за нарушения уникальности. Это связано с тем, что SET-обновления, выполненные на подписчике, распространяются репликацией в виде отдельных инструкций UPDATE для каждой затронутой строки.

• Если база данных подписчика секционирована горизонтально и имеются строки в секции, существующей на подписчике, но отсутствующей на издателе, подписчику не удастся обновить существовавшие ранее строки. При попытке обновить эти строки возвращается ошибка. Ряды должны быть удалены из таблицы и вставлены снова.

Пользовательские триггеры

• Если приложение требует наличия триггеров на подписчике, то эти триггеры должны определяться с параметром NOT FOR REPLICATION на издателе и подписчике. Это гарантирует, что триггеры сработают только для исходного изменения данных, и не будут активизированы, когда это изменение реплицируется.

  Убедитесь, что определяемый пользователем триггер не включается при обновлении таблицы триггером репликации. Это достигается посредством вызова процедуры sp_check_for_sync_trigger в теле пользовательского триггера. Дополнительные сведения см. в разделе sp_check_for_sync_trigger (Transact-SQL).

Немедленное обновление

• Для подписок с немедленным обновлением изменения на подписчике распространяются на издатель и применяются с использованием координатора распределенных транзакций Майкрософт (MS DTC). Убедитесь в том, что на издателе и подписчике установлен и настроен MS DTC. Дополнительные сведения см. в документации по Windows.

• Триггеры, используемые подписками с немедленным обновлением, требуют подключения к издателю для репликации изменений.

• Если публикация разрешает подписки с немедленным обновлением и статья в публикации имеет фильтр столбцов, вам не удастся отфильтровать столбцы, не допускающие значения NULL и не содержащие значений по умолчанию.

Обновление посредством очереди

• Таблицы, включенные в публикацию слиянием, не могут быть опубликованы и как часть публикации транзакций, разрешающей очереди обновляемых подписок.

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

• Для столбцов типа данных SQL_VARIANT: при вставке или обновлении данных на подписчике, когда они копируются с подписчика в очередь, агент чтения очереди сопоставляет данные следующим образом.

  • BIGINT, DECIMAL, NUMERIC, MONEYи SMALLMONEY сопоставляются с NUMERIC.

  • BINARY и VARBINARY сопоставляются с данными VARBINARY .

Обнаружение и разрешение конфликтов

• Для политики конфликтов с приоритетом подписчика: разрешение конфликтов не поддерживается для обновлений столбцов первичного ключа.

• Конфликты, возникающие из-за ошибок ограничений внешних ключей, не могут быть разрешены репликацией:

  • Если конфликты не ожидаются, и данные секционированы должным образом (подписчики не обновляют одни и те же строки), на издателе и подписчиках можно использовать ограничения внешних ключей.

  • Если ожидаются конфликты: не следует применять ограничения внешних ключей на издателе или подписчике, если используется политика разрешения конфликтов с приоритетом подписчика; не следует применять ограничения внешних ключей на подписчике, если используется политика разрешения конфликтов с приоритетом издателя.

Связанный контент

• Одноранговая репликация транзакций
• Репликация транзакций
• Публикация данных и объектов базы данных
• Subscribe to Publications