Подписчик

Распределительный

сервер

Агент

репликации

Распределительный

агент

подписчик

СТРАТЕГИИ РЕПЛИКАЦИИ

На практике выбирают одну из двух стратегий тиражирования данных в распределенной системе:

1. Тиражирование с полной репликацией– предусматривает размещение полной копии всей БД на каждом из узлов системы. РБД в данном случае называетсяполностью реплицированной. Стоимость устройств хранения данных и уровень затрат на передачу информации об обновлениях в этом случае будут самыми высокими. Для выполнения полной репликации рекомендуется использовать технологиюснимков (SNAPSHOT). Снимок представляет собой копию БД в определенный момент времени. Эти копии обновляются через некоторый заданный интервал времени, например, 1 раз в час или в сутки. Снимок можно обновить принудительно командойREFRESHSNAPSHOT.

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

СПОСОБЫ РАСПРОСТРАНЕНИЯ РЕПЛИКАЦИИ

Реплицируемые данные можно распространять целым рядом способов. Все методы распространения базируются либо на push-подписке (принудительная подписка), либо на pull-подписке (подписка по запросу). Подписчик может одновременно использовать сочетание push- и pull-подписок.

Push-подписка (принудительная)

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

Принудительную подписку обычно применяют, когда:

• число подписчиков относительно невелико;

• репликация выполняется в пределах локальной сети (INTRANET);

• необходима централизация управления репликацией.

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

Pull-подписка (по запросу)

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

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

Этот тип подписки снижает нагрузку сервера издателя/дистрибьютора, так как агенты распространения запускаются на стороне подписчиков.

Подписки по запросу подходят в следующих ситуациях:

• когда число подписчиков относительно невелико;

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

Подписки по запросу требуют большей работы по развертыванию и обслуживанию, чем принудительные.