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

Применимо к: SQL Server 2008 (и более поздние версии)

В SQL Server 2014 репликация транзакций поддерживает обновления на подписчиках с помощью обновляемых подписок и одноранговой репликации. Ниже приведены два типа обновляемых подписок:

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по использованию обновляемых подписок

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

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

• Репликация добавляет столбец 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 запрещено и будет отклонено из-за нарушения уникальности. Это связано с тем, что установка обновлений, сделанных на подписчике, распространяется репликацией в виде отдельных 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 данными.

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

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

• Конфликты из-за сбоев ограничений внешнего ключа не разрешаются репликацией:

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

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

См. также

Транзакционная репликация по принципу 'от равного к равному'
Репликация транзакций
Публикация объектов данных и баз данных
Подписка на публикации