Глава 2

Виды репликационных архитектур

В этой главе…

·        Единая БД с удаленным доступом на рабочих местах

·        Единая БД с обновляемыми копиями на других серверах

·        Распределенная БД

Единая БД с удаленным доступом на рабочих местах

            Это наиболее простой вид архитектуры для установки и администрирования. Работа осуществляется прямым доступом в удаленную БД через механизм Net8 и какой-либо протокол (в большинстве случаев TCP/IP). Поэтому необходимость в репликации отсутствует и проблем с несоответсвием данных на различных рабочих местах быть не может.

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

Тем не менее, этот режим работы применяется (либо применялся) в ряде Предприятий (без видимой разницы по сравнению с локальной сетью Объединения).

Единая БД с обновляемыми копиями на других серверах

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

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

Тем не менее, в случае длительной потери связи и интенсивных транзакциях накопившиеся изменения могут после восстановления связи либо «хлынуть» в БД-приемник  и «смыть» ее вместе с сервером (причем, такой же ущерб может принести БД-источнику обратная «волна» подтверждений), либо их выполнение «подвесит» систему на длительное и, возможно, неограниченное, время. В это время не исключены также зацикливания процессов («дедлоки», «смертельные объятия», «мертвые петли»). Кроме того, при возникновении сбоя или ошибки выполнения транзакции (что, несмотря на их «чистую» работу в БД-источнике, может быть связано с БД-приемником – например, изменение структуры таблиц или ее ограничений, удаление родительской записи…), ошибки могут нарастать каскадно, и их затем будет очень сложно анализировать. Особенно неустойчива для таких ситуаций ОС Novell Netware (см. Часть 2, Глава 4: ОС Novell Netware 5.0).

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

Недостатком данного вида архитектуры является необходимость и сложность ее регулярного администрирования (при ежедневных операциях с БД – ежедневного просмотра и устранения возможных ошибок), а также сложность установки (особенно это касается механизма Мультимастер) и настройки (в т.ч. привязывания клиентской части). Кроме того, какие-либо изменения свойств объектов механизма Мультимастер требуют перевода групп реплицируемых таблиц в состояние QUIESCED (молчащая), при которой запись в БД из клиентской части невозможна.

Распределенная БД

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

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

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

·         Когда правка классификаторов осуществляется централизованно (при этом они находятся на сервере головной организации), а правка рабочих таблиц – в дочерних организациях (эти таблицы находятся на их серверах).

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

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

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