8. Модели, методы и планирование репликации распределенных баз данных

МОДЕЛИ РЕПЛИКАЦИИ

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

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

сервер

подписчик

сервер

подписчик

2. Центральный издатель/Удаленный дистрибьютор.

сервер

подписчик

СЕРВЕР

удаленный дистрибьютор

сервер

подписчик

Эта модель используется для сокращения трафика между удаленными (от сервера-издателя) филиалами.

3.Центральный подписчик/Несколько издателей

подписчик

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

4.Несколько подписчиков/Несколько издателей

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

МЕТОДЫ РЕПЛИКАЦИИ

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

Репликация моментальных снимков (или просто репликация снимков,snapshot replication) – это наиболее простой и легко реализуемый метод репликации. При использовании репликации снимков периодически создается снимок (картина) базы данных, который распространяется подписчикам. Главным преимуществом репликации снимков является то, что она не требует непрерывной нагрузки на издателей и подписчиков. Издателям не нужно непрерывно следить за изменениями данных, а также не требуется непрерывной передачи данных подписчикам. Главным недостатком является то, что база данных у подписчика соответствует только последнему снимку базы данных издателя. Как правило, репликацию снимков применяют в тех случаях, когда данные серверов-подписчиков используются только для чтения или данные по своей природе являются редко обновляемыми (справочники) или объем данных не очень большой. Дополнительной причиной для применения этого метода может быть низкая пропускная способность сетевых соединений. Сеансы связи назначаются в то время, когда общая нагрузка на сеть наиболее низкая.

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

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

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

ПЛАНИРОВАНИЕ РЕПЛИКАЦИИ

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

На репликацию БД влияет несколько факторов, главные из которых:

• размер БД

• частота использования БД

• топология сети и ее пропускная способность.

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

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

• Очень важно собрать как можно больше сведений о будущих подписчиках и их пользователях, чтобы определить их цели и задачи. Следует принять во внимание аппаратные возможности серверов, количество обслуживаемых ими пользователей, способы подключения к серверам (TCP/IP, Multiprotocol, Namedpipes), полосу пропускания и надежность соединений. Количество подписчиков также влияет на выбор архитектуры репликации.

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

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

• Для выбора модели и метода репликации важна полоса пропускания соединения, его надежность и стоимость передачи данных. Очевидно, что лучше планировать репликационный обмен в часы самой высокой скорости передачи данных.

• Служба поддержки распределения Distribution Agentможет работать либо на дистрибьюторе, либо на подписчике. Агент требует большое количество ресурсов сервера, поэтому его лучше устанавливать на менее загруженный сервер.

• Репликация значительно усложняет работу СУБД-сервера: увеличивается рабочая нагрузка, возникает необходимость в дополнительном пространстве на жестком диске (для хранения реплицируемых данных, файлов снимков и базы данныхdistribution). Поэтому администратору нужно включать в проект репликации требования к оперативной памяти, быстродействию процессора и объему жесткого диска реплицируемых серверов. Чтобы правильно оценить эти требования, нужно учесть объемы реплицируемых данных, количество публикаций, количество статей в каждой публикации, частоту репликационного обмена и максимально возможную длительность хранения на издателе и дистрибьюторе подготовленных к тиражированию данных, а также обычную рабочую нагрузку серверов издателей и дистрибьюторов.

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

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

-----------------------------------------------------------------------------------------------------------------------