РЕПЛИКАЦИЯ ДАННЫХ В MICROSOFT SQL SERVER 2000

Источник: Мамаев Е. MS SQL Server 2000. -с.597-607

 Введение в репликацию данных.

SQL Server 2000 предлагает пользователям и администраторам множество различных средств обмена данными между самыми разнообразными системами с постоянным физическим соединением друг с другом или без него. В SQL Server 2000 имеется мощное средство обмена данными - репликация. Механизмы репликации данных представляют серверам SQL Server 2000 мощный фундамент для создания распределенных систем хранения информация с использование ODBC или OLE DB. Автоматическая синхронизация изменений (при постоянном физическом соединении или без него), сделанных на одном сервере, со всеми другими серверами делает возможным создание на основе SQL Server 2000 больших распределенных систем хранения информации, удовлетворяющих самым высоким современным требованиям.

Система репликации SQL Server 2000 основывается на технологии Replication Distribution Interface. Эта технология позволяет включать в репликацию данных не только серверы SQL Server 2000, SQL Server 7.0 или SQL Server 6.x, но и другие системы хранения и обработки данных, например, Microsoft Access, Oracle, dBase, Paradox. С помощью подсистемы репликации администратор может создать распределенные гетерогенные системы масштаба предприятия.

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

Начало активного применения репликации данных было положено появлением версии SQL Server 6.0. Модель репликации базируется на метафоре "опубликуй и подпишись" - Publish and Subscribe, введенных в том же SQL Server 6.0. Терминология репликаций использует понятие издатель - Publisher, дистрибьютор - Distributor, подписчик - Subscription.

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

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

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

- использование вертикального разделения, при которой в статью не включается одна или более колонок исходной таблицы;

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

Издателем в терминологии системы репликации SQL Server 2000 называется сервер, который предоставляет (публикует) расположенную на нем информацию другим серверам. Администратор конфигурирует на издателе публикацию, включающую одну или более статей. Для публикации устанавливается список пользователей, имеющих право копировать ее себе. На каждую публикацию могут подписаться один или более подписчиков, т.е. данные издателя могут быть отображены на множество других серверов - подписчиков. В свою очередь любой из серверов - подписчиков являться издателем для других серверов. Такой подход позволяет создавать сложные разветвленные информационные системы, наиболее оптимальным образом использующие сетевые соединения (рисунок 2).



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

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

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

Важным моментом является то, что данные могут изменится не только на издателе, но и на подписчике. Эта возможность появилась еще в SQL Server 7.0 и стала более функциональной в SQL Server 2000. Процесс изменения данных на подписчике не так прост, как кажется на первый взгляд. Если данные изменяются только на издателе, ситуация достаточно проста. Подписчики не могут вносить изменения, они должны лишь принимать изменения, сделанные на издателе. Изменение данных только на одном севере исключает возможность исключает возможность возникновения конфликтов изменений. Если же изменения в данные разрешено вносить и на подписчиках, то появление конфликтов изменения данных неизбежно. Предположим, что два пользователя пытаются одновременно исправить одну и тоже строку таблицы, причем значения, устанавливаемые пользователем различны. SQL Server 2000 должен каким-то образом решить этот конфликт, так как существование двух различных состояний для одних и тех же данных крайне нежелательно .Для решения подобных конфликтов в SQL Server 2000 существует три различных метода:

1. Репликация сведением - это самый сложный тип репликации. В этом случае допускается нахождение одних и тех же данных в нескольких различных состояний. То есть каждый из серверов - участников репликации может иметь свое собственное значение для одной и той же строки. Для решения этой проблемы используется система приоритетов, в соответствии с которой решается, данные какого из сервера должны быть тиражированы на все другие серверы.

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

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

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

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

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

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

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

Правильное применение дистрибьютора может существенно снизить сетевой трафик и затраты времени на синхронизацию серверов. Предположим, что организация имеет множество филиалов, удаленных на значительное расстояние. В некоторых крупных городах имеется по несколько филиалов. В центральном офисе располагается база данных, информация из которой должна быть скопирована на сервере филиала. Все серверы SQL Server 2000 связаны в единую сеть с помощью дорогих, но медленных наземных коммуникаций. Для распространения данных служит система репликаций. При выборе места размещения дистрибьютора сначала приходит решение установить его в центральном офисе. Действительно, в этом случае можно обойтись единственным дистрибьютором, который будет обслуживать всех подписчиков. Но следует обратить внимание, что серверы связаны посредством медленных наземных соединений. При таком подходе неизбежна многократная передача информация в города, имеющих несколько филиалов. Лучшим решением будет установка дистрибьютора в городе с нескольким подписчиками. В этом случае достаточно единожды скопировать данные из центрального офиса, а затем распространить их между всеми подписчиками в городе по недорогим и быстрым каналам местной связи. На ряду с финансовой выгодой такой подход может повысить скорость распространения изменений на все серверы информационной системы.