Методические указания для выполнения лабораторного практикума и самостоятельной работы студентов по дисциплинам «Базы данных», «Распределенные базы данных»




страница1/4
Дата04.08.2016
Размер0.68 Mb.
  1   2   3   4
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ АГЕНСТВО ПО ОБРАЗОВАНИЮ

КАБАРДИНО-БАЛКАРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ТЕХНОЛОГИЯ ДОСТУПА К БАЗАМ ДАННЫХ В ИНТЕРНЕТ

Методические указания

для выполнения лабораторного практикума

и самостоятельной работы студентов
по дисциплинам «Базы данных», «Распределенные базы данных», «Проектирование информационных систем в экономике»

Для специальностей: 230102 – Автоматизированные системы обработки

информации и управления;

230105 – Программное обеспечение вычислительной техники и автоматизированных систем;

080801 – Прикладная информатика в экономике.
НАЛЬЧИК 2008

1. Основные понятия технологии репликации данных

Репликация — это набор технологий, позволяющий поддерживать несколько копий одних и тех же данных базы данных (БД) на нескольких узлах сети [1].

Для распределения реплицированных данных используется модель, основанная на публикации и подписке. В эту модель входят следующие компоненты репликации: издатели, подписчики и дистрибьюторы.



Издателем (Publisher) является сервер – источник данных, подлежащих репликации. Для каждой таблицы или другого объекта БД, который предполагается использовать в качестве источника репликации, издатель определяет статью. Одна или несколько связанных статей из одной БД организуются в публикацию. Публикации представляют собой удобный способ группировки связанных данных и объектов, которые подлежат репликации [2].

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



Подписчиком (Subscriber) является сервер, который получат данные, реплицируемые издателем. Подписчик определяет подписку на необходимую ему публикацию. В подписке указывается срок получения (периодичность обновления) подписчиком публикации и сведения о соответствии между статьями публикации и таблицами или другими объектами подписчика. В зависимости от используемого метода репликации, подписчики могут или не могут вносить изменения в реплицируемые данные. В простейшем случае (метод репликации моментальных снимков - Snapshot Replication) изменять данные может только издатель. Измененные данные, полученные от всех подписчиков, синхронизируются и объединяются с данными, хранящимися на издателе, а затем снова рассылаются всем участникам репликации, включая и самого издателя.

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

Существует два метода обновления подписчиков:

Репликация по запросу (Pull subscription). Этот метод применяется в том случае, если подписчик периодически подключается к дистрибьютору и требует у него все изменения, сделанные со времени последнего подключения. При наличии большого количества подписчиков использование репликации по запросу позволяет снизить нагрузку на дистрибьютора.

Принудительная репликация (Push subscription). Этот метод используется в том случае, когда дистрибьютор сам устанавливает соединение с подписчиками и копирует им все необходимые данные. Использование этого метода репликации рекомендуется для серверов, с которыми постоянно установлено соединение. Изменения могут копироваться постоянно (в режиме on-line) или периодически на основе установленного расписания. Администратор дистрибьютора может централизованно управлять расписанием выполнения обновлений на всех подписках.

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



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

Для обозначения реплицируемых данных используются также термины «публикация» (Publication) и «статья» (Article).



Статья представляет собой таблицу или ее часть, предназначенную для тиражирования. Когда выбирается часть таблицы, используется либо вертикальное разделение (using a vertical filter) либо горизонтальное разделение (using a horizontal filter). Вертикальное разделение ограничивает количество колонок таблицы, включенных в репликацию. Горизонтальное разделение накладывает условие на выбираемые для тиражирования строки.

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

Таким образом, технология репликации представляет собой процесс автоматизации копирования (реплицирования) и распространения данных из одной таблицы или БД в другую таблицу или БД сети. Механизм репликации позволяет делать копии данных, тиражировать эти копии на другие серверы и узлы сети и автоматически синхронизировать изменения, внесенные в данные, так что все копии данных на всех узлах сети будут находиться в одинаковом состоянии.


2. Механизмы репликации

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



  • Snapshot Agent;

  • Log Reader Agent;

  • Distribution Agent;

  • Merge Agent;

  • Queue Reader Agent.

Программа инсталляции MS SQL Server 2000 не инициализирует механизмы репликации автоматически. Для реализации технологии репликации необходимо воспользоваться одним из мастеров, обеспечивающих выполнение репликации. При первом вызове, мастер определит, что поддержка репликации не установлена, и выполнит ее инициализацию. При этом появится соответствующее сообщение системы (рис.): После инициализации репликации на сервере добавится БД Distribution, а в консоли Enterprise Manager появится папка Replication Monitor [2].

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

Функции перечисленных агентов в реализации механизма репликации состоят в следующем:


  • агент создания снимков состояния (Snapshot Agent) подготавливает структуру данных и файлы, содержащие выбранные для репликации данные. Генерируемый этим агентом файл данных называется моментальным снимком (snapshot).

Независимо от используемого метода репликации необходимо выполнить первоначальную синхронизацию БД на издателе и подписчике. Для этого Snapshot Agent делает полную копию данных на издателе и сохраняет снимок на дистрибьюторе, откуда он затем копируется всем сконфигурированным подписчикам.

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



При каждом запуске Snapshot Agent выполняет следующие задачи [3]:

  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 освобождает блокировки, которые он захватывал по статьям и протоколирует снимок в файле журнала (истории);

    • агент чтения журнала (Log Reader Agent) используется при репликации транзакций. Он запускается на дистрибьюторе и подключается к издателю. Log Reader Agent копирует помеченные для репликации транзакции в БД дистрибьютора, откуда транзакции копируются всем подписчикам. Каждая публикация имеет своего агента Log Reader Agent, который подключается к издателю и копирует из журнала транзакции, которые были сделаны после операции копирования;

    • агент распространения (Distribution Agent) устанавливает соединение с подписчиком и копирует ему расположенные на дистрибьюторе данные, подготовленные Snapshot Agent и Log Reader Agent. При использовании репликации по запросу (pull subscription) Distribution Agent запускается на подписчике. Если же используется принудительная репликация (push subscription), то агент запускается на дистрибьюторе;

    • агент слияния (Merge Agent) применяется при репликации сведением (merge replication). Он отслеживает изменения, сделанные на подписчике со времени копирования снимка с издателя. Сделанные на всех подписчиках и издателе изменения собираются агентом, объединяются и затем тиражируются между всеми участниками репликации. Кроме того, Merge Agent отслеживает конфликты изменений, возникшие при изменении одной строки несколькими подписчиками. Такие конфликты решаются с помощью шкалы приоритетов, установленной для каждого подписчика. Данные при использовании репликации сведением могут перемещаться в обоих направлениях (сначала от подписчика к издателю, а затем обратно) или однонаправлено (только от подписчика к издателю). Каждая публикация репликации сведением имеет свой собственный Merge Agent, который устанавливает соединение, как с издателем, так и со всеми подписчиками. После синхронизации всех копий данных Merge Agent тиражирует обновленную копию всем участникам репликации - издателю и всем подписчикам. При использовании принудительной репликации сведением Merge Agent запускается на издателе. При конфигурировании репликации сведением по запросу Merge Agent запускается на подписке.

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

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

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

  1. В окне Enterprise Manager раскройте группу серверов и затем раскройте папку для сервера, используемого как дистрибьютор.

  2. Раскройте папку Replication Monitor и затем раскройте папку Agents (Агенты).

  3. Раскройте тип агента, за работой которого вы хотите наблюдать.

  4. В правой панели окна щелкните правой кнопкой мыши на агента, за которым вы хотите наблюдать, и выберите из появившегося контекстного меню пункта Agent History (Журнал работы агента) для просмотра журнала операций данного агента.



2.2. Запуск агентов

Агенты репликации запускаются с помощью заданий службы SQL Server Agent. Следовательно, они будут иметь те же права доступа, что и учетная запись, под которой стартует SQL Server Agent. Чтобы избежать проблем с разграничением доступа, можно запускать службу SQL Server Agentпод той же учетной записью, что и службу MS SQL Server.Перед началом процесса репликации следует убедиться, что служба SQL Server Agent запущена. Рекомендуется установить автоматический запуск этой службы при каждом запуске операционной системы. Однако указанные проблемы возникают, если агенты репликации используют аутентификацию Windows NT. Однако агенты также могут устанавливать соединение и с помощью аутентификации SQL Server, что позволяет предоставлять им права, отличные от прав службы SQL Server Agent.

Если просмотреть содержимое папки Management\SQL Server Agent\Jobs (рис.) на сервере, участвующем в репликации данных, то можно будет увидеть, что на нем имеется ряд заданий, относящихся к одной из категорий REPL.Эти задания как раз и реализуют работу агентов репликации.

Окно свойств задания STOPRAGE-pubs-1, обеспечивающего работу агента Log Reader Agent имеет следующий вид (рис.).

Интерес на вкладке General представляет только категория, к которой относится задание – REPL LogReader. В принципе, сам по себе выбор категории не играет особого значения, т.к. все действия, которые будет выполнять задание, конфигурируется на уровне отдельных шагов. С помощью поля New можно присвоить заданию более осознанное имя, чем предлагаемое по умолчанию. Имя задания не играет особого значения, т.к. на него нет ссылок из других подсистем. Именно поэтому изменение имени выполняется так просто. В поле Created указывается дата создания задания, по которой можно судить, как давно была инициирована репликация. Флажок Enable позволяет контролировать выполнение задания. Если флажок установлен, то задание может быть запущено. В случае, если необходимо гарантировать, что задание временно не будет выполняться, то достаточно лишь сбросить указанный флажок. Удалять задание в этом случае не потребуется.

Обратимся теперь ко вкладке Steps (рис.), с помощью которой конфигурируется собственно набор действий, выполняемых заданием. Как видно, задание состоит из трех шагов:



  • Log agent startup message;

  • Run agent;

  • Detect nonlogged agent shutdown.

Откроем окно свойств первого шага (рис.), выбрав его на вкладке Steps и нажав кнопку Edit. Как видно, шаг имеет тип Transact-SQL Script и выполняется в контексте БД Distribution, которая является БД распределения, которая создается на дистрибьюторе. Собственно шаг представлен единственной командой –вызов недокументированной системной хранимой процедуры sp_MSadd_logreader_history, которая имеется только в БД распределения. Назначение этой процедуры является всего-навсего создание в специальной системной таблице БД распределения записи о том, что был осуществлен запуск агента Log Reader Agent. Впоследствии по подобным записям можно восстановить ход работы агентов репликации. В принципе, если вы не хотите оставлять следов, можно удалить первый шаг издания.

Перейдя на вкладку Advanced (рис.) можно посмотреть какое действие будет выполнено после завершения выполнения шага. Как видно, независимо от результата выполнения первого шага будет запущен второй шаг.

Рассмотрим же теперь свойство второго шага задания (рис.). Этот шаг имеет тип Replication Transaction-Log Reader. Особенностью шагов этого типа является то, что они запускают утилиту командой logread.exe, реализующую агента Log Reader Agent. Текст, приведенный в поле Command, является ничем иным как ключами запуска этой утилиты, с помощью которой указывается конкретный набор действий и их параметры, подлежащие выполнению агентом.

Перейдя на вкладку Advanced (рис.) можно увидеть, что в случае успешного завершения работы утилиты logread.exe (поле On success action) работа всего задания завершится и будет возвращен код успешного завершения задания (значение Quit the job reporting success). В случае неудачного завершения шага (поле On failure action) будет выполнен следующий шаг (значение Goto the next step). Однако перед этим будет предпринято 10 попыток (поле Retry attempts) выполнения утилиты с интервалом в одну минуту (поле Retry interval (minutes)).

В завершение рассмотрим свойства третьего шага задания (рис.), который, как уже стало ясно, выполняется лишь в случае неудачного выполнения всех 10 попыток запуска утилиты logread.exe. Как видно из рисунка, шаг имеет тип Transact-SQL Script (TSQL) и представляет собой выполнение недокументированной системой хранимой процедуры sp_MSadd_logreader_history, которая вносит соответствующую запись БД распределения о неудачном завершении запуска агента Log Reader Agent.

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

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

Интерес также представляет и время запуска агента Log Reader Agent. Для получения этой информации необходимо в окне свойств задания перейти на вкладку Schedules (рис.). Как видно, для задания определено всего одно расписание запуска. В столбец Description можно просмотреть расписание запуска задания. Как видно, задание запускается каждый раз при старте службы SQL Server Agent (Start automatically when SQL Server Agent Starts). Запущенное однажды, оно загружает утилиту logread.exe, которая в дальнейшем функционирует как самостоятельный процесс операционной системы. Таким образом, нет нужды запускать агента каждый раз, когда необходимо обновить данные. Открыв менеджера задач (Task Manager) и перейдя на вкладку Processes (рис.), можно заметить, что утилита logread.exe находится в оперативной памяти. Там же можно увидеть, как ее объем используется этой утилитой.

Открыть менеджера задач можно с помощью комбинаций клавиш Ctrl+Shift+Esc, или нажав в свободной части панели задач правую кнопку мыши и в открывшемся контекстном меню выбрать пункт меню Task Manager. Можно также нажать комбинацию клавиш Ctrl+Alt+Del и воспользоваться кнопкой Task Manager. Отметим, что указанные действия относятся только к операционной системе Windows NT 4.0 и Windows 2000.

На этом рассмотрение задачи, выполняющей запуск агента Log Reader Agent, можно считать окончательным. Вкладка Notifications при автоматическом создании задания средствами мастеров поддержки репликации не конфигурируется. Однако, если вы хотите извещать какого-то оператора о неудачном запуске агента, то ничто не мешает этого сделать.

Мы на примере агента Log Reader Agent объяснили общие принципы запуска агентов репликации. Конфигурирование других агентов не имеет особых отличий.

3. Модели репликации

В SQL Server используются три модели репликации: репликация моментальных снимков, репликация транзакций и репликация слиянием. Эти модели репликации поддерживают различные уровни согласованности данных в реплицированной БД, и они налагают различную нагрузку на серверы.


3.1. Репликация моментальных снимков

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

Репликация моментальных снимков выполняется двумя агентами – Snapshot Agent и Distribution Agent (рис.).

Каждый раз, когда запускается Snapshot Agent, он подготавливает файл данных моментального снимка (snapshot file), который впоследствии будет копироваться подписчикам. Технология работы данного агента реализуется пошагово:

шаг 1. Snapshot Agent запускается на дистрибьюторе и устанавливает соединение с издателем. Затем агент устанавливает коллективную блокировку (share-lock) на все таблицы, для которых определены статьи публикации. Блокировка гарантирует поддержку целостности данных, то есть пользователь не может удалить скопированную агентом строку, а затем снова вставить ее в конец таблицы. Кроме того, пользователи не могут вносить изменения в заблокированные таблицы;

шаг 2. Snapshot Agent подключается с издателя к дистрибьютору и записывает копию структуры (схемы) каждой статьи в файл с расширением .sch на дистрибьюторе. Файл сохраняется в подкаталоге того каталога, в котором расположена БД Distribution. Для проиндексированной на издателе статьи создается скрипт для создания индекса, который сохраняется в файле с расширением .idx на дистрибьюторе;

шаг 3.Агент делает копию данных из публикуемой издателем таблицы и сохраняет ее в файле на дистрибьюторе. Как и файлы схемы, файлы моментальных снимков копируются в подкаталог каталога БД Distribution. Для создания моментальных снимков используется технология массивного копирования с помощью утилиты bcp.exe, при этом создаются файлы моментальных снимков с расширением .bcp или .txt в соответствии с версией сервера. Сгенерированные таким образом файлы с расширением .sch и .bcp синхронизированы для конкретной статьи, то есть число колонок, их тип, размер и другие свойства в файле моментального снимка соответствуют данным в файле схемы;

шаг 4. Snapshot Agent добавляет строки в таблицы Msrepl_commands и Msrepl_transactions БД распределения Distribution. В таблице Msrepl_commands сохраняется информация о местонахождении файлов .sch и .bcp, а также всех скриптов, сохраненных в файлах с расширением .idx, которые должны быть выполнены на подписчике перед началом копирования данных. В таблице Msrepl_transactions описываются задания синхронизации подписчиков;

шаг 5. Агент снимает блокировку таблиц издателя и записывает информацию о проделанных действиях в журнал событий (log history file).

После того как агент Snapshot Agent завершит свою работу, на дистрибьюторе будет находиться вся информация, необходимая для создания на подписчиках копий статей издателя. Затем на Distribution Agent возлагается задача доставить подписчикам данные, подготовленные Snapshot Agent. Эта функция выполняется в несколько шагов:



шаг 1. Distribution Agent устанавливает соединение с сервера, на котором он запущен, с дистрибьютором. Если используется репликация по запросу, то агент запускается на подписчике. Если же используется принудительная репликация, то агент запускается на дистрибьюторе;

шаг 2. Агент просматривает БД Distribution и анализирует содержимое таблиц Msrepl_commands и Msrepl_transactions. Если агент обнаруживает новые записи в таблицах, он считывает информацию о расположении файлов схемы, моментального снимка и скриптов;

шаг 3. Агент выполняет содержащийся в файле схемы скрипт для создания на подписчике таблицы с нужной структурой. Distribution Agent, предварительно выполнив необходимые преобразования кода, начинает копирование данных из файла моментального снимка в созданные таблицы. При этом используются механизмы массированного копирования средствами утилиты bcp.exe и командой BULK INSERT.
3.2. Репликация транзакций

Репликация транзакций используется для репликации изменений, вносимых в БД (рис.). При использовании этого метода любые изменения, вносимые в статьи, немедленно считываются из журнала транзакций и распространяются дистрибьюторам. Используя репликацию транзакций, можно поддерживать издателя и его подписчиков почти всегда в синхронизированном состоянии. Репликацию транзакций используют в тех случаях, когда необходимо поддерживать все реплицируемые системы на уровне текущих изменений. Репликация транзакций накладывает на систему более высокую нагрузку, чем репликация снимков, поскольку она обеспечивается в режиме on-line либо с минимальными задержками (всего несколько секунд). Поэтому репликация транзакций поддерживает систему в более согласованном состоянии, чем репликация снимков и репликация слиянием.

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

Из журнала транзакций выбираются все транзакции, в ходе которых были выполнены команды изменения данных INSERT, DELETE, UPDATE. Полученная информация сохраняется в базе распределения Distribution на дистрибьюторе. При этом указывается информация о порядке выполнения транзакций. При выполнении синхронизации на подписчике применяются все транзакции, хранящиеся в БД Distribution. Причем в той же последовательности, в которой они происходили на издателе.

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

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

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

Этот метод репликации функционирует с помощью трех агентов:


  • Snapshot Agent;

  • Log Reader Agent;

  • Distribution Agent.

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

Первоначальная синхронизация происходит по схеме работы репликации моментальных снимков. Агент Snapshot Agent подключается к издателю и создает набор файлов, используемых в стандартной репликации моментальных снимков – файл схемы (SCH), сценарий создания индексов (IDX) и файлы моментальных снимков (BCP или TXT). Затем эти файлы сохраняются на дистрибьюторе.

После того как создание файлов первоначальной синхронизации будет закончено, начинается отслеживание изменений в статьях. Для этого на дистрибьюторе запускается агент Log Reader Agent, который и устанавливает соединение с издателем, просматривает журнал транзакций публикуемой БД и выбирает из него все транзакции, в которых было произведено изменение публикуемых данных. Таким образом, будут найдены все команды INSERT, DELETE, UPDATE, выполненные на издателе, а также любые другие команды изменения данных.

Транзакции, которые изменяли публикуемые данные на издателе, автоматически отмечаются специальным образом. Помеченные транзакции не удаляются из журнала транзакций даже при усечении журнала и остаются там до тех пор, пока не будут скопированы в БД распределения на дистрибьюторе. Кроме того, пометка транзакций позволяет ускорить процесс их поиска агентом Log Reader Agent.

В SQL Server 2000 имеется набор системных хранимых процедур, с помощью которых производится управление процессом репликации. Эти хранимые процедуры позволяют выполнить любые необходимые действия. Например, для получения с издателя списка транзакций, помеченных для репликации, применяется хранимая процедура sp_replcmds. Чтобы снять отметку с транзакции и тем самым разрешить ее удаление, применяется процедура sp_repldone.

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

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

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

Distribution Agent подключается к БД распределения дистрибьютора и анализирует содержимое таблицы Msrepl_transactions. Если он находит в таблице транзакции, еще не отображенные на подписчике, то он применяет их в том же порядке, в котором они выполнены на издателе. Это гарантирует согласованность данных между издателем и всеми подписчиками. Принцип работы агента Distribution Agent при использовании репликации транзакций практически ничем не отличается от работы в случае репликации моментальных снимков.
3.3. Репликация слиянием

Репликация слиянием (репликация сведением) выполняется аналогично репликации транзакций, поскольку она следит за всеми изменениями, вносимыми в статьи, но передает эти изменения в пакетном режиме (рис.). В данном методе каждый подписчик может независимо изменять свою копию данных, не копируя немедленно сделанные изменения издателю. Причем несколько подписчиков могут одновременно изменять одни и те же данные, что не обеспечивается технологией моментальных снимков. Специальный агент отслеживает сделанные на всех участниках репликации изменения, собирает их на дистрибьюторе, анализирует и решает, какие изменения следует принять, а какие – отменить. Это решается с помощью шкалы приоритетов. Для каждого участника репликации устанавливается свой приоритет, причем издатель имеет самый высокий приоритет. Например, если два подписчика изменили одну и ту же строку, то агент проверит, какой подписчик имеет более высокий приоритет и тиражирует сделанные этим подписчиком изменения все участникам репликации, включая подписчика с меньшим приоритетом.

Этот метод репликации функционирует с помощью двух агентов:



  • Snapshot Agent (рис.) выполняет первоначальную синхронизацию БД подписчика и издателя;

  • Merge Agent (рис.) отслеживает сделанные на участниках репликации изменения и разрешает конфликты сведения.

Сложность репликации сведением состоит в отслеживании автономных изменений, сделанных каждым участником репликации, и их объединение в единую копию. Модификация данных выполняется автономно, поэтому невозможно избежать конфликтов изменений. Они происходят, когда два или более участников репликации исправляют у себя одни и те же данные. Механизмы репликации должны решить, какое из изменений должно быть оставлено, а какое – потеряно. Для решения описанных задач при создании публикации репликации сведением в структуре таблиц должны быть выполнены несколько важных трансформаций:

    • SQL Server 2000 должен предоставлять возможность уникально идентифицировать каждую строку таблицы для сопоставления изменений, сделанных на каждом участнике репликации. Идентификатор не должен изменяться с течением времени, поэтому в качестве него применяются глобальные уникальные идентификаторы (GUID, Global Unique Identifier). Значение каждого из которых, хранятся в колонках специального типа – uniqueidentifier. Этот тип разработан для хранения глобальных идентификаторов и для других целей не используется. Поэтому вероятность генерирования двух одинаковых значений GUID практически равна нулю. При создании публикаций репликации сведением SQL Server 2000 ищет в таблице, включенной в публикацию, колонку с типом данных uniqueidentifier и установленным свойством ROWGUIDCOL. Если такая колонка уже существует, то она будет использована автоматически. В противном случае создается колонка с именем ROWGUID, удовлетворяющая всем указанным требованиям. Кроме того, эта колонка автоматически идентифицируется для ускорения операций поиска. Идентификация строк в репликации сведением по колонке timestamp недопустима, так как для этой колонки при каждом изменении строки будет генерироваться новое значение. Тогда как значения в колонке uniqueidentifier генерируется при создании строки и не меняются с течением времени.

    • Каждый из участников репликации должен самостоятельно отслеживать изменения, которые вносятся им в реплицированные данные. Для этого в каждой таблице, включенной в репликацию, создаются специальные триггеры, которые автоматически вызываются при каждом выполнении команд INSERT, DELETE, UPDATE и сохраняют все выполненные изменения в специальных таблицах. Триггеры могут отслеживать изменения, как на уровне всей строки, так и на уровне отдельной колонки. Характерной особенностью репликации сведением является отслеживание изменений, что стало возможным благодаря тому, что SQL Server 2000 поддерживает одновременно множество триггеров каждого типа. Триггеры репликации SQL Server 2000 успешно работают вместе с пользовательскими триггерами.

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

После внесения всех необходимых изменений в БД можно приступать к репликации данных. Как и репликация транзакций, репликация сведением требует выполнение первоначальной синхронизации данных на издателе и подписчиках. Шаги, выполняемые при первоначальной синхронизации репликации сведением, ничем не отличаются от аналогичных шагов в случае репликации транзакции. Основной этап – подготовка файлов моментальных снимков (BCP или TXT), файлов схемы (SCH) и скриптов (IDX) – выполняется агентом Snapshot Agent, который запускается на дистрибьюторе и подключается к издателю.

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

Агент Merge Agent запускается на дистрибьюторе, в случае принудительной репликации, и на подписчике, если сконфигурирована репликация по запросу.

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

После успешного завершения первоначальной синхронизации подписчики могут отключиться от дистрибьютора и начать изменения данных. Триггеры будут автоматически сохранять информацию о внесенных исправлениях в таблицы поддержки репликации на каждом из подписчиков и издателе. Данные об изменениях во всех реплицируемых таблицах хранятся в таблице Mamerge_contents. Для связи с самими данными предназначен столбец ROWGUID, хранящий уникальный идентификатор исходной строки. Таблица, к которой принадлежит строка, идентифицируется по колонке TABLENICK. В колонке GENERATION указывается номер сеанса, в котором было произведено изменение. Таким образом, в таблице Mamerge_contents хранится информация обо всех изменениях в реплицируемых таблицах, сделанных пользователями. Любая модифицированная в БД строка отображается в единственную строку таблицы Mamerge_contents. При многократном изменении одной и той же строки в таблице Mamerge_contents сохраняется только последнее изменение.

Изменения, производимые пользователями в таблицах, не будут отображены на других участниках репликации до тех пор, пока не произойдет сведение (merge) данных. Выполняя сведение, Marge Agent подключается к дистрибьютору и сохраняет в БД распределения Distribution информацию об изменениях на локальном сервере. Новая информация сливается с информацией об изменениях, полученной от других участников репликации. Если не возникают конфликты изменения (любая строка данных изменялась только на одном участке репликации), то Marge Agent забирает информацию об изменениях, проделанных на других участках репликации, и применяет их на локальном сервере. На этом процесс сведения заканчивается.

Но часто одни и те же данные бывают модифицированы на нескольких серверах. В этом случае агент Marge Agent должен разрешить конфликт сведения и определить, изменения какого сервера должны быть приоритетными и будут применены на всех участниках репликации. Для решения этой задачи применяются специальные алгоритмы, в основе которых лежит шкала приоритетов. Для каждого сервера устанавливается свой приоритет по 100-балльной шкале. Чем выше приоритет сервера, тем больше вероятность того, что его изменения пройдут. Наибольший приоритет имеет издатель. Помимо шкалы приоритетов, при разрешении конфликтов сведения предназначен номер сеанса (колонка GENERATUIN) и счетчик изменений в строке (колонки LINEAGE и COLVL). Номер сеанса увеличивается при каждом сведении данных.

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

Система репликации SQL Server 2000 построена таким образом, что пользователи могут определять свои собственные правила разрешения конфликтов, отличные от стандартных. Это можно сделать при помощи либо специальных хранимых процедур, либо интерфейса COM.

  1   2   3   4


База данных защищена авторским правом ©uverenniy.ru 2016
обратиться к администрации

    Главная страница