Репликация данных

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

Сервер, реплицирующий сохраненную информацию на другие серверы, называется издателем (publisher). Реплицируемая информация состоит из одной или нескольких публикаций (publications). Каждая публикация представляет собой логически согласованный набор данных отдельной БД и состоит из одной или нескольких статей (articles). Статья может быть одним или несколькими объектами следующего типа:

- часть или целая таблица (с фильтрацией по столбцам и/или по строкам);

- хранимая процедура или определение представления;

- выполнение хранимой процедуры;

- представление;

- индексированное представление;

- пользовательская функция.

В процессе репликации каждый издатель взаимодействует с распространителем (distributor), который сохраняет публикуемые БД, историю событий и метаданные. Распространитель может быть как локальным (тот же экземпляр SQL Server), так и удаленным (отдельный экземпляр SQL Server).

Серверы, получающие реплицируемую информацию, называются подписчиками (subscribers). Они получают избранные публикации - подписки (subscriptions) - от одного или нескольких издателей. В зависимости от типа репликации, подписчикам может быть разрешено изменять реплицируемую информацию, а также реплицировать измененную информацию обратно издателю.

SQL Server 2000 поддерживает три типа репликации - моментальных снимков, транзакций и сведением. Рассмотрим каждый из типов подробнее.

Репликация моментальных снимков (snapshot replication) - это периодическая репликация целостного набора данных, зафиксированного по состоянию на определенный момент времени, с локального сервера на удаленные. При репликации моментальных снимков агент Snapshot периодически (по заданному расписанию) копирует все помеченные для репликации данные с сервера-издателя в папку моментальных снимков распространителя. Агент Distribution периодически копирует все данные из папки моментальных снимков на каждый сервер-подписчик и, используя эти данные, полностью обновляет на нем публикацию. Агент Snapshot выполняется на распространителе, а агент Distribution может выполняться как на распространителе, так и на каждом сервере-подписчике. Оба агента записывают информацию журналов событий и журнала ошибок в БД распространения. Этот тип репликации обычно используется в БД, где количество реплицируемых данных невелико, а источник данных статичен. Можно предоставлять удаленным серверам ограниченную возможность обновления реплицированных данных.

Репликация транзакций (transactional replication) - это репликация начального моментального снимка данных на удаленные серверы, а также репликация отдельных транзакций, работающих на локальном сервере и выполняющих последовательные изменения данных в начальном моментальном снимке. При репликации транзакций агент Snapshot создает исходный моментальный снимок данных, помеченных для репликации, и копирует его с сервера-издателя в папку моментальных снимков распространителя. Агент Distribution направляет полученный снимок каждому подписчику. Агент Log Reader следит за изменениями данных, участвующих в репликации, и фиксирует каждое изменение журнала транзакций в БД распространения на сервере-распространителе. Агент Distribution отправляет каждое изменение всем подписчикам в первоначальном порядке выполнения этих изменений. Если хранимая процедура используется для обновления большого количества записей, можно реплицировать эту процедуру, а не каждую обновленную строку. Все три этих агента репликации заносят информацию о событиях и ошибках в БД распространения. Подписчики при наличии сетевого соединения с издателем могут получать изменения почти в реальном времени. После того как все подписчики получат реплицированные транзакции, агент Distribution Clean Up удаляет эти транзакции из БД распространения. Данный тип репликации можно использовать, если необходимо постоянное обновление данных на удаленных серверах.

Репликация сведением (merge replication)- это репликация начального моментального снимка данных на удаленные серверы, а также репликация изменений, происходящих на каком-либо удаленном сервере, обратно на локальный сервер с целью синхронизации, разрешения конфликтов и повторной репликации на удаленные серверы. При репликации сведением агент Snapshot передает начальный моментальный снимок данных, участвующих в репликации, от издателя в папку моментальных копий распространителя. Агент Merge направляет полученный снимок каждому подписчику. Также он анализирует и объединяет изменения реплицируемых данных, выполняемые издателем и подписчиками. Если при объединении изменений происходит конфликт на издателе, агент Merge разрешает его, используя указанный администратором способ. Можно выбрать одно из существующих средств обнаружения конфликтов или создать свое собственное. Оба агента заносят информацию о событиях и ошибках в БД распространения. Лучше использовать репликацию сведением в случае, когда многочисленным изменениям подвергаются одни и те же данные, либо когда удаленные независимые компьютеры работают автономно, например, как в случае автономного пользователя.

Обычно репликацию организуют средствами мастеров, доступных в консоли SQL Server Enterprise Manager.

Настроить свойства распространителя и издателя можно при помощи мастера Configure Publishing And Distribution Wizard. Запустить мастер Configure Publishing And Distribution Wizard можно из окна Select Wizard (рисунок 22).

Рис 22. Вызов мастера Configure Publishing And Distribution Wizard

Щелкните Далее, чтобы сделать локальный сервер распространителем или выбрать распространителя для уже сконфигурированного издателя. Откроется окно Select Distributor (рисунок 23).

Рис 23. Выбор распространителя

По умолчанию предлагается сделать распространителем локальный сервер, а также создать БД распространения и журнал транзакций. Чтобы выбрать удаленный сервер, он уже должен быть сконфигурирован в качестве распространителя. Кроме того, для выбора удаленного сервера его следует предварительно зарегистрировать в SQL Server Enterprise Manager. Также должны иметься соответствующие права доступа к удаленному распространителю.

Если в качестве распространителя выбран локальный сервер, откроется окно Specify Snapshot Folder, где можно указать размещение папки моментальных снимков. Далее в окне Customize The Configuration можно изменять свойства распространителя или принять параметры по умолчанию (рисунок 24).

Рис 24. Выбор параметров распространителя

В последнем окне мастера Completing The Configure Publishing And Distribution Wizard можно просмотреть все выбранные параметры (если не были выбраны параметры по умолчанию). По завершении работы с мастером Configure Publishing And Distribution Wizard откроется окно SQL Server Enterprise Manager с сообщением о том, что в дерево консоли добавлен контейнер Replication Monitor.

После настроек свойств распространителя необходимо создать публикацию. Если публикация создается впервые, удобней воспользоваться мастером Create Publication Wizard. Он может быть из окна на рисунке 22, далее откроется окно мастера Welcome To The Create Publication Wizard. Для отображения дополнительных параметров настройки можно пометить флажок Show Advanced Options In This Wizard, что позволит создавать обновляемые подписки и трансформируемые подписки.

Далее в окне Choose Publication Database выберите БД с данными и объектами, которые требуется публиковать. Если мастер Create Publication Wizard запущен членом роли сервера sysadmin, отображаются все пользовательские БД и автоматически разрешается репликация любой выбранной БД. Если же мастер запущен членом роли db_owner, будет разрешена репликация тех БД, владельцем которых является db_owner. В окне Select Publication Type выберите тип публикации (рисунок 25). Можно создать публикацию снимка, транзакционную публикацию и публикацию сведением.

Рис 25. Выбор типа публикации

Если в окне Select Publication Type выбрана публикация сведением, открывается окно мастера Specify Subscriber Types, где можно выбрать какие типы подписчиков смогут подписаться на данную публикацию. Далее откроется окно Specify Articles, в котором необходимо выбрать таблицы для публикаций (рисунок 26).

Рис 26. Выбор таблиц БД для публикации

Для того чтобы просмотреть и изменить режим разрешения конфликтов для публикации сведением или изменить другие параметры репликации, надо нажать кнопку Article Defaults.

При выборе следующего шага открывается окно Article Issues, в котором сообщается, какие необходимые дополнения будут автоматически созданы для корректной работы репликации. Далее в окне Select Publication Name And Description необходимо задать имя и описание публикации. В следующем окне Customize The Properties Of The Publication предлагается создать дополнительные фильтры на публикуемые данные или оставить текущую конфигурацию, описанную здесь же (рисунок 27).

Рис 27. Подтверждение создания публикации с заданными ранее параметрами

После подтверждения последнего шага откроется окно SQL Server Enterprise Manager, где отображается состояние процесса создания публикации.

После создания публикации любого типа, можно средствами Push Subscription Wizard настроить на издателе принудительную подписку на нее. Принудительные подписки централизованно инициируются и управляются издателем. Запустить мастер Create Push Subscription Wizard можно из окна Select Wizard (рисунок 22). Откроется окно Create and Manage Publications, где надо выбрать публикацию, на которую следует создать принудительную подписку (рисунок 28), и нажать кнопку Push New Subscription. Откроется окно Welcome To The Push Subscription Wizard. Если в этом окне пометить флажок Show Advanced Options In This Wizard, при дальнейшей работе с мастером вы сможете задать параметры обновляемой подписки, а также сконфигурировать соответствующий агент репликации для работы на подписчике, а не на распространителе. В следующем окне Choose Subscribers выберите подписчиков, которым будет распространяться публикация. Далее в окне Choose Destination Database надо выбрать конечную БД для репликации.

Рис 28. Выбор публикации для создания подписки

В следующем окне Set Merge Agent Schedule задается частота обновления агентом подписки (рисунок 29). По умолчанию агент Merge запускается каждый час, однако можно установить собственное расписание запуска, нажав на кнопку Change.

Рис 29. Выбор частоты обновления агентом подписки

Затем в окне Initialize Subscription надо указать, когда следует инициализировать подписку. В окне Set Subscription Priority задается приоритет подписок для подписки на публикацию сведением. По умолчанию установливается переключатель Use The Publisher As A Proxy For The Subscriber When Resolving Conflict. Это устанавливает нулевой приоритет для всех подписчиков. Издатель объединяет изменения, выполненные подписчиком, и присваивает их авторство. Подписка без назначенного приоритета называется локальной (local subscription). Можно самостоятельно установить приоритет подписки, установив переключатель Use The Following Priority Between Zero (Lowest) And 99.99 (Highest), To Resolve The Conflict. Подписка с установленным приоритетом называется глобальной (global subscription). В таком случае изменения, выполненные подписчиком, объединяются с данными издателя; при этом приоритет каждого подписчика, выполнившего изменения, сохраняется в составе метаданных для этого изменения. Это гарантирует, что на изменение, выполненное подписчиком с более высоким приоритетом, не накладывается изменение, внесенное подписчиком с более низким приоритетом.

Далее открывается окно Start Required Services, где агент SQL Server проверяет, что на распространяющем данные сервере запущены все необходимые службы. Если нужная служба не запущена, SQL Server Agent по умолчанию запустит ее, когда мастер завершит работу. Для того, чтобы запускать службу вручную, не помечайте соответствующий флажок. Наконец, в окне Completing The Push Subscription Wizard можно просмотреть заданные параметры подписок и щелкнуть Finish для создания принудительной подписки.

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