Репликации

Лекция 9. Репликации

Одним из важнейших элементов системы SQL Server является служба репликации данных.

Следует подчеркнуть, что служба репликации является составной частью стан­дартной версии SOL Server, поскольку поставщики других СУРБД рассматривают средства репликации как отдельный продукт, за который необходимо вносить до­полнительную плату.

По сути, репликация является службой, осуществляющей гарантированное копиро­вание информации из исходной базы данных в одну или более целевых. Средства ре­пликации Microsoft SQL Server позволяют организовать автоматическую рассылку данных некоторого сервера на несколько других серверов с использованием ODBC (Open Database Connectivity— открытый интерфейс баз данных) или OLE DB. Ис­пользуя средства ODBC или OLE DB, SQL Server 2000 обеспечивает репликацию дан­ных в адрес получателей, не относящихся к системам SQL Server (смешанная репли­кация), например Microsoft Access и Oracle. Поддерживаются также анонимные под­писчики в Internet. Кроме того, SQL Server 2000 позволяет непосредственно обновлять подписчиков и осуществлять репликацию методом слияния, что сущест­венно расширяет возможности репликации.

С учетом нововведений количество возможных вариантов решений, доступных при создании приложений, становится просто ошеломляющим!

Перечислим приложения или сценарии, в которых могут применяться средства репли­кации SQL Server.

• Для распределения нагрузки между серверами в сети (например, для передачи

произвольных запросов или отчетов на обработку серверу, отличному от исходного).

• Для перемещения определенных поднаборов данных (например, данных неко­торого подразделения или данных за установленный период) с главного цен­

Рекомендуемые материалы

трального сервера на вспомогательные.

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

если отдел сбыта изменяет цену на определенную продукцию).

• В приложениях, используемых торговыми агентами или представителями для

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

их компьютеров к сети.

• Для организации в Web группы пользователей с помощью приложения, позволяющего благодаря функции подписки периодически извлекать через Internet

сведения об изменениях в общей базе данных.

• В распределенных вычислительных средах, в которых серверы импортируют

информацию из файлов с ее дальнейшей репликацией на другие узлы.

Публикация и подписка

В системе репликации SQL Server используются понятия публикация (publish) и подписка (subscribe). Серверы системы публикуют свои данные (публикации), на ко­торые могут подписаться другие серверы. В среде SQL Server сервер, который делает свои данные доступными для подписки со стороны других серверов, называется пуб­ликующим.

Публикации и статьи

Публикующий сервер предоставляет набор из одной или более статей, называе­мый публикацией (publication). Публикация, включает выбранные табли­цы. Термин статья (article) используется по отношению к базо­вым объектам репликации, которые могут представлять собой отдельную таблицу, некоторую часть таблицы или хранимые процедуры.

Каждая публикация может содержать один или более перечисленных ниже эле­ментов.

• Таблица.

• Вертикальное разделение таблицы.

• Данные хранимой процедуры (новая функция в SQL Server 2000).

• Горизонтальное разделение таблицы.

• Горизонтальное и вертикальное разделение таблицы

Вертикальное разделение таблицы представляет собой статью, в опре­делении которой используется фильтр, выделяющий в таблице только заданные столбцы.

Горизонтальное разделение таблицы представляет собой статью, в определении которой используется фильтр, выделяющий в таблице только задан­ные строки данных.

Однако существуют объекты, которые не могут публиковаться.

• Базы данных model, tempdb и msdb.

• Системные таблицы, расположенные в базе данных master.

Типы подписки

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

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

Роли серверов

В общей схеме процессов репликации системы SQL Server каждый сервер может выполнять одну или более перечисленных ниже ролей.

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

серверам-подписчикам.

• Сервер-подписчик (subscriber) получает и обрабатывает публикуемые данные.

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

становится публикующим сервером. (Любая информация в системе может пуб­ликоваться только одним-единственным сервером.)

• Рассылающий сервер (distributor) содержит базу данных рассылки и отвечает

за хранение и пересылку адресатам информации о синхронизации и реплика­ции транзакций. Назначение рассылающего сервера — доставка на все серверы-

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

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

Нет ничего необычного в том, что сервер-подписчик одновременно играет роль публикующего сервера. Однако в системе репликации SQL Server установлено, что для каждой публикации может существовать лишь одна ведущая копия базы данных, поддерживаемая публикующим сервером, независимо от числа серверов-подпис­чиков, которым предоставлено право вносить изменения в данную публикацию. Например, в системе с репликацией методом слияния сервер А публикует базу данных pubs. Серверы В и С являются подписчиками и имеют право вносить в эту базу дан­ных изменения. Ведущая копия базы данных, в которую будут поступать сведе­ния обо всех изменениях, находится на публикующем сервере А. Изменения, выпол­ненные на сервере С, поступят на сервер В после репликации через сервер А.

Внешние системы, отличные от SQL Server (например, Oracle и Microsoft Access), могут выступать в качестве подписчиков для всех существующих типов репликации (за исключением непосредственно обновляемых подписчиков). Кроме того, Microsoft предоставила разработчикам открытый интерфейс службы репликации транзакций системы SQL Server. В результате третьи фирмы получили возможность создавать программные продукты, позволяющие отличным от SQL Server системам выступать в качестве гетерогенных источников публикуемой информации.

Типы репликации

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

Репликация транзакций

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

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

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

Синхронизация

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

Репликация методом слияния

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

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

Непосредственно обновляемые подписчики

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

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

Согласованность транзакций

В контексте репликации данных согласованность транзакций означает, что на всех узлах данные будут иметь идентичные состояния, соответствующие тому, которое могло возникнуть при выполнении всех транзакций на одном и том же узле. Репликация вно­сит в процессы некоторый элемент случайности, который выражается в появлении оп­ределенных временных задержек между моментом выполнения изменения в данных и моментом репликации этих сведений подписчикам. В SQL Server 2000 задержки репли­кации относятся к одному из двух возможных вариантов согласованности транзакций: гарантированной неполной согласованности (guaranteed loose consistency) и гарантированно­му отсутствию согласованности (guaranteed no consistency).

Гарантированная неполная согласованность означает, что синхронизация данных между сервером-источником и сервером-получателем не выполняется немедленно. Прежде чем подробнее остановиться на этом варианте, рассмотрим еще одну модель распределенных данных — гарантированную точную согласованность (guaranteed tight consistency). Она может быть реализована в SQL Server с использованием двухступен­чатого протокола фиксации изменений. В этой модели все выполняемые транзакции либо фиксируются, либо отменяются одновременно на всех серверах, поэтому дан­ные всех серверов всегда синхронизированы на 100%.

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

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

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

База данных рассылки

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

Системные таблицы, входящие в состав базы данных рассылки.

• MSmerge_history — содержит информацию о выполненных ранее обновлениях подписчиков.

• MSmerge_agents — содержит сведения об агентах слияния.

• MSdistribution_agents — содержит сведения об агентах рассылки.

• MSdistribution_history — содержит информацию для агентов рассылки.

• MSlogreader agents — содержит сведения об агентах чтения журнала на локальном рассылающем сервере.

• MSlogreader_history — содержит информацию для агентов чтения журнала.

• MSrepl_commands — содержит команды репликации.

• MSrepl errors — содержит сведения о неудачных попытках выполнения про­

цедур репликации.

• MSrepl_transactions — содержит отдельную строку для каждой подлежащей

репликации транзакции.

• MSrepl version — содержит единственную строку со сведениями о версии те­

кущей установленной службы репликации.

Обзор агентов репликации SQL Server

Для эффективного управления работой системы репликации SQL Server необхо­димо подробно ознакомиться с различными агентами, используемыми в процессах репликации.

Все существующие типы агентов:

• Агент чтения журнала (log reader). Анализирует наличие в журнале транзакций публикуемой базы данных записей об отдельных транзакциях, подлежащих

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

• Агент слияния (merge agent). Отвечает за слияние поступающих изменений, а

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

агента синхронизации.

• Агент синхронизации (snapshot agent). Создает файлы синхронизации на рассылающем сервере и фиксирует в базе данных рассылки статус информации о

синхронизации между публикуемой базой данных и базами данных серверов-

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

• Агент рассылки (distribution agent). Отвечает за рассылку серверам-

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

Рекомендация для Вас - 1. Организационная структура.

В публикациях по методу репликации транзакций и синхронизации имеются

отдельные агенты рассылки для каждого сервера-подписчика.

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

Варианты согласования

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