Обзор статьи "Database Replication"
DBMS, vol.10, N 5, May 1997, www.dbmsmag.com

Charles Thompson, manager at a large consulting firm in Wellington, New Zeland, DBMS@mfi.com
Обзор подготовлен С. Кузнецовым, Центр Информационных Технологий

• Microsoft SQL Server 6.5
• Oracle 7 Release 7.3
• Sybase SQL Server System 11

Хотя перспективность распределенных баз данных уже давно признана, до последнего времени соответствующая технология была либо слишком ограниченной, либо чересчур сложной. Сегодня ситуация изменилась. У каждой из основных компаний, производящих СУБД, имеется решение относительно реплицированных баз данных; многие компании, не связанные напрямую с базами данных, предлагают альтернативные методы репликации.

В статье рассматривается и сравнивается технология репликации, применяемая в трех из шести ведущих компаний, производящих СУБД: Microsoft Corp., Oracle Corp. и Sybase. Автор не поясняет свой выбор, но отмечает, что развитой технологией репликации располагают и компании Informix Software Inc., IBM Corp., Computer Associates International Inc. Кроме того, репликация может быть основана на использовании промежуточного программного обеспечения, например, Tuxedo или TopEnd.

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

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

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

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

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

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

Множественные обновления - это ночной кошмар архитекторов систем с репликацией. Часто было бы гораздо проще допустить обновление любых данных на любом сервере и автоматически реплицировать обновления на все другие серверы. Конечно, проблемой является возможность обновления одних и тех же данных на разных серверах. Традиционное решение состоит в назначении одного сервера-источника, что приводит к архитектуре, близкой к первому сценарию. Более сложная технология репликации допускает наличие архитектуры со множественными обновлениями; администратор системы получает возможность произвольно решать, какие данные "корректны". Конфликты обрабатываются алгоритмами разрешения конфликтов, которые обычно основаны на одном из следующих методов:

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

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

1. установить генераторы ключей с предопределенным диапазоном значений, разным для каждого сервера;
2. добавлять к первичному ключу идентификатор сервера;
3. производить репликацию в разные таблицы и читать все данные через представление с объединением; для работы с ключами дубликатами можно использовать псевдостолбец, представляющий базу данных - источник.

Microsoft SQL Server 6.5

Технология баз данных компании Microsoft происходит от Sybase. Первая версия MS SQL Server была почти идентична Sybase SQL Server, но потом две системы развивались по-разному. В частности, это касается механизма репликации.

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

Реплицированная база данных создается просто, с использованием удобного пользовательского интерфейса SQL Enterprise Manager, но эту базу данных может быть очень трудно поддерживать. Каждый сервер может быть одновременно публикатором, подписчиком и распространителем; одна и та же таблица может одновременно содержать реплицированные и исходные данные. Кроме того, опыт автора и его коллег показывает, что система работает недостаточно устойчиво, а поскольку можно делать почти все, что угодно, администратор должен очень тщательно продумывать архитектуру.

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

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

Для второго сценария (мобильные данные) Microsoft имеет незаконченное решение. В качестве мобильной базы данных можно использовать ядро Jet (из Access или Visual Basic). Microsoft позволяет производить ограниченную репликацию на Jet через ODBC. Это новая возможность версии 6.5, и она не позволяет производить полную репликацию. В SQL Server и Jet используются разные версии SQL, и у Jet меньше возможностей, так что мобильные приложения должны несколько отличаться от стационарных. Однонаправленная репликация небольших объемов данных может сработать, но если потребуется более сложная распределенная база данных, придется включить в мобильное приложение специально написанные подпрограммы репликации.

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

Oracle 7 Release 7.3

Имеется несколько разновидностей Oracle Server: Universal Server, Parallel Server, Enterprise Server, Workgroup Server и т.д. Все серверы выполняют одинаковый набор базовых функций, но включают разные опции и выполняются на разных платформах. С точки зрения репликации, наибольший интерес представляют Enterprise и Workgroup серверы. Между эти продуктами имеется три основных различия:

1. Workgroup Server существенно дешевле;
2. Enterprise Server предназначен для использования на средне- или крупномасштабных серверах, а Workgroup Server - на более мелких серверах;
3. Развитая репликация (Advanced Replication) доступна только на Enterprise Server.

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

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

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

Основное ограничение состоит в том, что для неполных мгновенных снимков допускается до 16 попыток передачи, после чего требуется ручное вмешательство. Ограничены и возможности мгновенных снимков. Быстрый снимок, например, должен базироваться на одной таблице, а также для него нужно определить журнал мгновенного снимка на стороне сервера и мгновенный снимок на стороне целевого компьютера. Мгновенный снимок выполняется в отдельном процессе операционной системы; из-за особенностей именования этих процессов в любой момент времени может обрабатываться не более 10 мгновенных снимков.

Новейшая технология репликации компании Oracle доступна только в Enterprise Server. Механизм развитой репликации основан на использовании хранимых процедур системного уровня (выполняемых как "задания"), триггеров, запросов и связей с базами данных. При применении этой системы вы можете точно определить, что нужно реплицировать - полные таблицы или только изменения. Можно запрограммировать свой собственный алгоритм разрешения конфликтов. Репликация может быть синхронной и асинхронной, причем этот режим можно менять. Механизм встроен в сервер и управляется интерпретатором SQL или инструментами администратора, поскольку все команды - это операторы SQL и вызовы хранимых процедур. Однако лучшим средством управления развитой репликацией является компонент Enterprise Manager, называемый Replication Manager и позволяющий создавать группы репликации, что делает большую сложную сеть гораздо более управляемой.

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

Oracle предлагает ряд решений для мобильного клиента, но ни одно из них не является полностью адекватным. Можно использовать следующие продукты:

• Personal Oracle 7, однопользовательскую версию сервера со всеми возможностями Enterprise Server;
• Oracle Lite, гораздо менее масштабную систему со всеми серверными возможностями (за исключением поддержки PL/SQL);
• другие базы данных с использованием Oracle Mobile Agents.

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

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

Mobile Agents - это новая технология конфигурирования асинхронных задач для мобильных компьютеров. Агент состоит из API и процесса на стороне клиента, координирующего процесс на сервере. Опять проблема в том, что для использования агента требуется написать собственный код.

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

Sybase SQL Server System 11

Для управления репликацией Sybase использует отдельный продукт - Replication Server, отдельный набор процессов с собственным командным языком (хотя можно обращаться к нему через интерпретатор ISQL). Репликация в Sybase доступна с 1993 г., раньше, чем ее обеспечили Microsoft и Oracle. Используется схема публикации и подписки.

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

Механизм, используемый в Replication Server, похож на применяемый Microsoft, но в нем используются процессы операционной системы. В дополнение к процессу Replication Server для каждого публикатора требуется Replication Agent. Он читает журнал файлов и передает соответствующие записи об изменении данных в Replication Server, который транслирует их подписчикам. Replication Agent основан на использовании Open Connectivity, что позволяет использовать базы данных, управляемые не Sybase SQL Server.

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

Sybase - это единственная компания, предлагающая законченное решение для построения мобильных приложений. SQL Anywhere (ранее система Watcom) теперь полностью совместима, вплоть до Transact SQL, с SQL Server. Это позволяет запускать на мобильных компьютерах приложения без изменений. Для поддержки репликации данных используется SQL Remote. Этот продукт не настолько полон и гибок как Replication Server, но он обеспечивает базовый уровень репликации достаточный для поддержки мобильных приложений без специального программирования.

Replication Server поддерживает множественные обновления реплик, предоставляя полный контроль над разрешением конфликтов: можно выбрать встроенный алгоритм или запрограммировать свой собственный.