Лекция 26: Репликация в Microsoft SQL Server: обзор типов репликации и репликация моментальных снимков

Публикации

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

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

Push-подписка и pull-подписка

Реплицируемые данные можно распространять целым рядом способов. Все методы распространения базируются либо на push-подписке (принудительная подписка), либо на pull-подписке (подписка по запросу). Подписчик может одновременно использовать сочетание push- и pull-подписок.

Push-подписка (принудительная)

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

Использование push-подписки дает вам высокий уровень гибкости в планировании графика репликаций. Push-подписки можно конфигурировать таким образом, чтобы распространять изменения сразу после их реализации или выполнять модификации на основе какого-либо регулярного расписания. Более подробная информация по этим возможностям приводится в разделе "Конфигурирование репликации моментальных снимков" ниже в этой лекции.

Pull-подписка (по запросу)

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

Агенты репликации

Для выполнения операций, необходимых для перемещения реплицируемых данных от издателя к дистрибьютору и затем подписчику, используются несколько агентов: Snapshot Agent, Log Reader Agent, Distribution Agent и Merge Agent. В этом разделе вы узнаете, что делают эти агенты и как управлять ими.

Snapshot Agent (Агент создания снимков состояния)

Агент Snapshot Agent используется для создания и распространения снимков мгновенного состояния от издателя дистрибьютору (или в местоположение снимка). Snapshot Agent создает данные репликации (снимок), а также создает информацию (метаданные), которая используется агентом Distribution Agent для распространения этих данных. Snapshot Agent сохраняет снимок на дистрибьюторе (или в указанном вами месте). Snapshot Agent также обеспечивает поддержку информации о состоянии синхронизации объектов репликации; эта информация хранится в дистрибутивной базе данных.

Snapshot Agent большую часть времени находится в неактивном состоянии и может периодически активизироваться в соответствии с заданным вами расписанием для выполнения своих задач. При каждом запуске Snapshot Agent выполняет следующие задачи.

1. Snapshot Agent устанавливает соединение от дистрибьютора к издателю. Если соединение недоступно, то Snapshot Agent не продолжает создание снимка. После установления соединения Snapshot Agent блокирует все статьи, участвующие в репликации, чтобы обеспечить согласованность данных в снимке. (По этой причине не стоит планировать репликацию снимков на периоды пиковой нагрузки.)
2. Snapshot Agent устанавливает соединение от издателя к дистрибьютору. После установления этого соединения Snapshot Agent формирует копию схемы для каждой статьи и сохраняет эту информацию в дистрибутивной базе данных. Эти данные трактуются как метаданные.
3. Snapshot Agent получает снимок реальных данных издателя и записывает их в файл в местоположении для снимка. Местоположением снимка не обязательно является дистрибьютор. Если в репликации участвуют только системы, относящиеся к SQL Server, то файл сохраняется как собственная программа массового копирования. (Массовое копирование описывается в "Загрузка базы данных" .) Если в репликации участвуют системы различных типов, то данные сохраняются в текстовых файлах. На данном этапе информация для синхронизации указывается агентом Snapshot Agent.
4. После копирования данных Snapshot Agent обновляет информацию в дистрибутивной базе данных.
5. Snapshot Agent освобождает блокировки, которые он захватывал по статьям и протоколирует снимок в файле журнала (истории).

Как видите, Snapshot Agent обеспечивает только создание снимка; он не распространяет его подписчикам. Эту задачу выполняют другие агенты.

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

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

Log Reader Agent (Агент чтения журнала)

Агент Log Reader Agent используется в репликации транзакций для извлечения информации об изменениях из журнала транзакций на издателе для репликации этих команд в дистрибутивную базу данных. Каждая база данных, использующая репликацию транзакций, имеет собственного агента Log Reader Agent на издателе. (О Log Reader Agent см. "Репликация транзакций" .)

Distribution Agent (Агент распространения)

Агент Distribution Agent распространяет снимки и транзакции из дистрибутивной базы данных подписчикам. Каждая публикация имеет собственного агента Distribution Agent. Если вы используете push-подписку, то Distribution Agent выполняется на дистрибьюторе. Если вы используете pull-подписку, то Distribution Agent выполняется на подписчике.

Merge Agent (Агент слияния)

Агент Merge Agent используется в репликации слиянием для согласования (слияния) накопившихся изменений, выполненных с момента последнего согласования. Если вы используете репликацию слиянием, то агенты Distribution Agent и Snapshot Agent не используются: взаимодействие с издателем и дистрибьютором осуществляет Merge Agent. (О Merge Agent см. "Репликация слиянием" .)

Queue Reader Agent (Агент очередей)

Агент Queue Reader Agent используется для распространения выполненных изменений подписчикам репликации снимков или репликации транзакций, которые были сконфигурированы с опцией отложенных обновлений (Queued updating). Эта опция позволяет вносить изменения на подписчике без необходимости использования какой-либо распределенной транзакции.

Мониторинг работы агентов

Вы можете следить за любым из агентов с помощью Enterprise Manager. Для этого выполните следующие шаги.

1. В окне Enterprise Manager раскройте группу серверов и затем раскройте папку для сервера, используемого как дистрибьютор.
2. Раскройте папку Replication Monitor и затем раскройте папку Agents (Агенты).
3. Раскройте тип агента, за работой которого вы хотите следить.
4. В правой панели щелкните правой кнопкой мыши на агенте, за которым вы хотите следить, и выберите из появившегося контекстного меню пункт Agent History (Журнал работы агента) для просмотра журнала операций данного агента.