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 выполняет следующие задачи.
Snapshot Agent устанавливает соединение от дистрибьютора к издателю; если соединение недоступно, то Snapshot Agent не продолжает создание снимка; после установления соединения Snapshot Agent блокирует все статьи, участвующие в репликации, чтобы обеспечить согласованность данных в снимке;
Snapshot Agent устанавливает соединение от издателя к дистрибьютору; после установления этого соединения Snapshot Agent формирует копию схемы для каждой статьи и сохраняет эту информацию в дистрибутивной базе данных; эти данные трактуются как метаданные;
Snapshot Agent получает снимок реальных данных издателя и записывает их в файл в местоположении для снимка; местоположением снимка не обязательно является дистрибьютор; если в репликации участвуют только системы, относящиеся к SQL Server, то файл сохраняется как собственная программа массового копирования; если в репликации участвуют системы различных типов, то данные сохраняются в текстовых файлах; на данном этапе информация для синхронизации указывается агентом Snapshot Agent;
после копирования данных Snapshot Agent обновляет информацию в дистрибутивной базе данных;
Snapshot Agent освобождает блокировки, которые он захватывал по статьям и протоколирует снимок в файле журнала.
Таким образом, Snapshot 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.
Queue Reader Agent (Агент очередей)
Агент Queue Reader Agent используется для распространения выполненных изменений подписчикам репликации снимков или репликации транзакций, которые были сконфигурированы с опцией отложенных обновлений (Queued updating). Эта опция позволяет вносить изменения на подписчике без необходимости использования какой-либо распределённой транзакции.
Репликация транзакций
Репликация транзакций обычно начинается с создания моментального снимка объектов и данных базы данных публикации. Как только создан исходный моментальный снимок, последующие изменения данных и схемы на издателе обычно доставляются подписчику без задержек (практически в реальном времени). Изменения данных применяются на подписчике в том же порядке и в тех же рамках транзакций, в которых они выполнялись у издателя. Поэтому в пределах публикации гарантируется согласованность транзакций.
Репликация транзакций обычно используется в серверных средах и пригодна в следующих случаях:
необходимо, чтобы добавочные изменения распространялись подписчикам без задержек по мере появления;
для приложения необходимы малые задержки между моментом внесения изменений на издателе и моментом прибытия изменений подписчику;
для приложения необходим доступ к промежуточным состояниям данных; например, если строка изменяется пять раз, репликация транзакций позволяет приложению реагировать на каждое изменение (например, срабатывание триггера), а не просто на итоговое изменение строки;
на издателе выполняется очень большой объём вставок, обновлений и удалений;
издатель и подписчик являются базами данных, отличными от баз данных SQL Server (например, Oracle).
По умолчанию подписчики на публикации транзакций должны быть доступны только для чтения, так как изменения не распространяются обратно на издателя. Однако репликация транзакций предоставляет возможности, позволяющие выполнять обновления у подписчика.
Репликации транзакций поддерживают типы публикаций, приведённые в таблице 13.1.
Таблица 13.1.
Типы публикаций, поддерживаемые репликацией транзакций
Тип публикации |
Описание |
Стандартная публикация транзакций |
Подходит для топологий, в которых все данные подписчика доступны только для чтения (репликация транзакций не устанавливает принудительно этот вид доступа на подписчике). Стандартные публикации транзакций создаются по умолчанию, если используется Transact-SQL или объекты RMO. Если используется мастер создания публикации, публикации транзакций создаются путем выбора Публикация транзакций на странице Тип публикации. |
Публикации транзакций, поддерживающие обновляемые подписки в иерархической топологии |
Эта топология более всего подходит для подписчиков, которые делают изменения только время от времени. Характеристики этого типа публикации:
|
Публикации транзакций в одноранговой топологии |
Эта топология более всего подходит для серверных сред, в которых требуется высокий уровень масштабируемости доступности и чтения. Характеристики этого типа публикации:
|
Репликация транзакций реализуется агентом моментальных снимков, агентом чтения журналов и агентом распространителя SQL Server. Агент моментальных снимков готовит файлы моментальных снимков, содержащие схему, данные публикуемых таблиц и объекты базы данных, хранит файлы в папке моментальных снимков и записывает задания синхронизации в базу данных распространителя на распространителе.
Агент чтения журнала контролирует журнал транзакций всех баз данных, настроенных для репликации транзакций, и копирует транзакции, отмеченные для репликации, из журнала транзакций в базу данных распространителя, которая действует как надежная очередь с функциями хранения и переадресации данных. Агент распространителя копирует файлы исходного моментального снимка из папки моментальных снимков и транзакции, хранимые в таблицах базы данных распространителя, на подписчики.
На рисунке 13.2. показаны основные компоненты репликации транзакций.
рис. 13.2. Основные компоненты репликации транзакций
Добавочные изменения, вносимые на издателе, поступают подписчикам согласно расписанию агента распространителя, который может выполняться непрерывно для достижения минимальной задержки либо в запланированные интервалы времени. Поскольку изменения данных должны вноситься на издателе (когда репликация транзакций используется без немедленного обновления и отложенного обновления), возникновение конфликтов обновления исключается. В конечном счёте, для всех подписчиков устанавливаются такие же значения, как и на издателе. Если с репликацией транзакций используется немедленное или отложенное обновление, в этом случае обновления могут вноситься на подписчике, и для отложенного обновления возможно возникновение конфликтов.