Михаил Острогорский
Хорошо, когда все корпоративные данные существуют в единственном (не считая резервных копий) экземпляре и хранятся централизовано. Это существенно облегчает обеспечение их целостности, непротиворечивости и безопасности. А еще хорошо, когда корпоративные данные существуют во множестве экземпляров, каждый сотрудник носит свой экземпляр в ноутбуке и может в нужное время и в нужном месте обратиться к нему. Последнее относится к компаниям, в которых работает много мобильных сотрудников, нуждающихся в доступе к корпоративным данным. Поскольку данные находящиеся как на сервере компании, так и на компьютерах "блуждающих" сотрудников могут изменяться, возникает проблема их синхронизации. Необходимо, чтобы изменения, сделанные в одной из копий БД, как можно быстрее были внесены в другие копии, а возникающие при этом противоречия в данных как-нибудь разрешались. Для решения этой проблемы существует технология репликации данных в децентрализованных информационных системах.
Децентрализованные системы не следует путать с распределенными. Распределенные системы состоят из некоторого ограниченного более-менее постоянного числа серверов, на которых хранятся таблицы БД. Сервера подключаются к локальной или глобальной сети и могут все время обмениваться данными. Для синхронизации данных в распределенных системах обычно используется механизм двухфазной фиксации транзакций. Децентрализованные системы состоят из одного или нескольких соединенных между собой основных серверов и множества не имеющих постоянного соединения с ними компьютеров, на которых находятся активно используемые полные или частичные копии основной БД. Эти компьютеры могут в случайные моменты времени устанавливать связь с основными серверами, последним же остается только дожидаться, когда интересующий их компьютер будет доступен. Синхронность данных в подобных системах обеспечивает механизм децентрализованной репликации. И вот что еще важно: децентрализованная система - это не тоже самое, что система "клиент/сервер", а мобильные компьютеры - это не клиенты. Они тоже серверы, только маленькие, - на них ведь тоже находятся данные.
Системы децентрализованной репликации начали появляться на рынке с 1993 г. Более простые, называемые "насосами данных" (data pumps), копируют данные с основного сервера на компьютеры сотрудников. Как правило, они основаны на применении оператора SELECT к таблицам, которые подлежат обновлению. Более изощренные системы перемещают между основными серверами и мобильными компьютерами не сами данные, а запротоколированные транзакции, произошедшие на каждой из машин с момента последнего сеанса синхронизации, в котором они участвовали. Чем больше объем данных, тем меньше доля измененных данных и тем выгоднее перекачивать не данные, а изменения. Разумеется, в системах репликации предусмотрены средства разрешения конфликтов, возникающих, когда одни и те же данные по разному изменяются на разных машинах.
Децентрализованные системы обычно гетерогенны в том смысле, что в них могут быть задействованы несколько различных серверов БД. Например, на основном сервере может функционировать Oracle, а на серверах LAN, настольных компьютерах и ноутбуках что-нибудь более простое и дешевое.
Рассмотрим, как реализованы функции децентрализованной репликации данных в продуктах компании Centura Corporation. Имеющиеся в SQLBase средства репликации данных основаны на использовании транзакций. SQLBase может работать в гетерогенной среде и обеспечивает целостность данных даже в том случае, если одни и те же данные изменяются по-разному на разных машинах. SQLBase хорошо приспособлен для построения систем, в которых есть мобильные случайным образом выходящие на связь пользователи, работающие с небольшими локальными БД и периодически синхронизирующие их с основной БД. SQLBase позволяет задавать, какие данные с какими пользователями будут синхронизироваться, при помощи графического интерфейса point-and-click.
Centura Ranger - это локальная версия сервера БД SQLBase, снабженная развитыми средствами репликации. Эта СУБД может использоваться на мобильных компьютерах, в то время, как на основных серверах будет работать SQLBase или другой сервер БД.
Репликация в продуктах Centura заключается в создании репликационных наборов и последующем обмене ими между двумя видами серверов: серверами-издателями (replication publishers) и серверами-подписчиками (replication subscribers). Издатель - это сервер, на котором хранится основная БД, и с которого подписчики получают обновленные данные. Функции сервера-издателя может выполнять SQLBase или какой-нибудь "неродной" сервер вроде Oracle. Серверами - подписчиками должны быть серверы SQLBase или Centura Ranger.
Процесс репликации в Cen-tura состоит из трех фаз: определения репликационных наборов, инициализации и синхронизации.
Определение репликационных наборов производится на сервере-издателе посредством интерфейса Replication Management System, который является частью SQLConsole, утилиты для администрирования БД в SQLBase. Этот интерфейс напоминает Microsoft File Manager, в котором рабочее пространство состоит из двух панелей. Используя технологию drug-and-drop, пользователь определяет, какие таблицы будут участвовать в репликации при синхронизации основной БД с копиями БД, находящимися у различных пользователей. Тут же задаются некоторые опции. Меняя эти опции, можно настроить систему на работу в режиме "насоса данных" или в режиме обмена транзакциями и задать способ обработки противоречий, возникающих при синхронизации. При сохранении определенного в Replication Management System репликационного набора, на сервере-издателе генерируются теневые таблицы, в которых будут сохраняться все изменения, происходящие с БД, а также триггеры, которые будут фиксировать эти изменения в теневых таблицах. У каждого репликационного набора существует флаг разрешения/запрещения репликации. Если этот флаг установлен, то репликационный набор задействуется, иначе - нет. Администратор БД может устанавливать или сбрасывать флаг в любое время.
После того, как определены все репликационные наборы, необходимо скопировать структуру БД, описания репликационных наборов и собственно данные на каждый из серверов-подписчиков. В этом и состоит инициализация. Фактически инициализация происходит во время первого с момента определения репликационных наборов сеанса синхронизации. В процессе инициализации на сервере-подписчике создается все необходимое для репликации, в том числе и локальные теневые таблицы, в которых фиксируются все изменения, сделанные на сервере-подписчике.
Синхронизация - это собственно и есть процесс приведения в соответствие данных на сервере-издателе с данными на сервере-подписчике. Синхронизация не требует участия или уведомления администратора БД на сервере-издателе. Этот процесс инициируется пользователем сервера-подписчика тогда, когда ему это необходимо или удобно.
Синхронизация состоит из следующих пяти последовательных шагов:
Одна из самых заковыристых проблем, возникающих при репликации данных, это, конечно, разрешение противоречий в данных.
В SQLBase предусмотрено три способа разрешения противоречий. Во-первых, при определении репликационных наборов можно установить опции таким образом, что противоречия вовсе не будут возникать. Во-вторых, можно задать способы автоматического разрешения возникающих противоречий. И, в-третьих, противоречия могут разрешаться администратором БД вручную.
Если возникновение противоречий допускается, то они выявляются на сервере-издателе в процессе сравнения данных, поступивших с сервера-подписчика, с данными, хранящимися в теневых таблицах сервера-издателя. Если противоречия обнаруживаются, то вызвавшие их строки заносятся в специальную теневую таблицу для последующего автоматического или ручного разрешения.
Хотя противоречия возникают на уровне строк, разрешаются они на уровне транзакций. Все строки, которым не повезло оказаться в одной транзакции со строкой, вызвавшей противоречие, попадают в теневую таблицу, а соответствующие изменения откладываются до момента разрешения противоречия.
Щедрая фирма Centura Corpo-ration, дает разработчикам три способа предотвратить возникновение противоречий. Первый заключается в том, что строки просто распределяются между серверами-подписчиками так, что с каждой строкой может работать только один сервер-подписчик.
Второй способ - сделать репликацию однонаправленной. Изменения, сделанные на сервере-издателе, будут переноситься на сервер-подписчик, а наоборот - нет. Можно выбрать настройки так, что одни изменения будут передаваться в обоих направлениях, а другие только в одном. Например, результаты операции INSERT будут передаваться на сервер-издатель, а результаты операций UPDATE и DELETE - нет. Соответствующие опции могут быть заданы для отдельных таблиц.
Третий способ напоминает "китайскую ничью". Репликация прекращается, как только возникает первое же противоречие.
В ряде случаев обновление одной и той же информации в нескольких местах одновременно может быть вполне естественно и закономерно. Например, если несколько сотрудников работают с одним клиентом. В этом случае SQLBase позволяет задать правила, по которым противоречия будут разрешаться автоматически. Подобные правила заключаются либо в назначении приоритетов серверам обоих типов, либо в задании формулы, по которой из нескольких значений полей получается одно результирующее. Так, для численных полей к значению некоторого поля БД сервере-издателе может прибавляться сумма разностей этого значения и значений этого поля на каждом из серверов-подписчиков.
При ручном разрешении противоречий, транзакция, в которую попадает строка, вызвавшая это противоречие, откладывается. Администратор БД может просматривать и лично ликвидировать выявленные противоречия с помощью интерфейса Conflict Manager, который также является частью SQLConsole. Conflict Manager позволяет сравнивать спорные строки, пришедшие с сервера-подписчика, с соответствующими строками БД на сервере-издателе, изменять значения полей в этих строках, завершать отложенные транзакции или откатывать их.
