В СУБД SQL Server предусмотрена возможность использовать для репликации источники данных различных типов. В настоящее время транзакционная репликация и репликация снимков поддерживаются на всех платформах операционных систем, предназначенных для эксплуатации СУБД Oracle, а также на большинстве платформ операционных систем, на которых может эксплуатироваться СУБД DB2.

Области применения репликации снимков

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

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

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

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

Специальные требования к планированию

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

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

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

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

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

Подписчик

Изменившиеся данные

Издатель

Опубликованные данные

Данные для репликации

Разрешение конфликтов

Подписчик

Изменившиеся данные

Рис. 20.4. Схема функционирования системы репликации путем слияния

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

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

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

Агент слияния

Программа агента используется не только в системе с репликацией снимков, но и в системе репликации путем слияния, если не считать того, что в последней эта программа называется агентом слияния (Merge Agent). Как показано на рис. 20.5, агент копирует данные об изменениях, полученные от всех подписчиков, и применяет их к базе данных издателя. После этого агент слияния копирует все изменения, накопленные в базе данных издателя (включая изменения, внесенные самим агентом слияния в процессе разрешения конфликтов), по базам данных подписчиков. При использовании push-подписок программа агента слияния обычно эксплуатируется на том же компьютере, что и распределитель, а если репликация осуществляется на основе pull-

Данные от издателя

Изменения

Изменения

Данные от издателя

Подписчик

Подписчик

Рис. 20.5. Принципы функционирования агента слияния