• Статья

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

ПримечаниеПримечание

В будущей версии Microsoft SQL Server эта возможность будет удалена. Избегайте использования этой возможности в новых разработках и запланируйте изменение существующих приложений, в которых она применяется.

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

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

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

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

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

Включение обновляемых подписок для публикаций транзакций

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

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

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

ПримечаниеПримечание

Репликация не переключает режимы обновления автоматически. Необходимо установить режим обновления через среду Среда SQL Server Management Studio, либо ваше приложение должно вызвать хранимую процедуру sp_setreplfailovermode (Transact-SQL) для переключения режима обновления.

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

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

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

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

Общие рекомендации

  • Обновляемые подписки поддерживаются для подписчиков, использующих Microsoft SQL Server 2000 с пакетом обновления 3 (SP3) или более поздние версии.

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

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

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

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

Определяемые пользователем триггеры

  • Если приложение требует наличия триггеров на подписчике, то эти триггеры должны определяться с помощью параметра NOT FOR REPLICATION на издателе и подписчике. Дополнительные сведения об этом параметре см. в разделе Управление ограничениями, идентификаторами и триггерами с помощью параметра «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.

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

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

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

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

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