В одном или нескольких
В одном или нескольких узлах (СУБД), которым нужны измененные данные, в обслуживающем его
репликационном сервере создается подписка (subscription) на соответствующее описание
тиражирования. Здесь будет поддерживаться (с небольшой задержкой) копия первичных
данных.
Современные СУБД используют системный журнал, в который делаются записи о изменениях в
базе данных и завершении транзакций. Журнал используется сервером БД для отката и доката
транзакций после сбоев и для резервного копирования. Репликация данных в Sybase также
использует журнал как источник информации о завершенных транзакциях.
В узле, содержащем первичные данные, для каждой тиражируемой базы данных запускается
специальная компонента - репликационный агент (Replication Agent - RA). Он подключается к
серверу БД и получает от него уведомления о завершении транзакций. Измененные данные
передаются репликационному серверу, обслуживающему этот узел. Репликационный сервер в
соответствии с описанием тиражирования и подписками отправляет данные в специальном
эффективном протоколе по месту назначения - соответствующим репликационным серверам в
удаленных узлах.
Именно в этом месте - между репликационными серверами - связь может быть медленной или
недостаточно надежной. Передаваемые данные в составе транзакции при недоступности узла-
получателя записываются в стабильные очереди на диске и затем передаются по мере возможности.
Данные могут передаваться в удаленный узел по маршруту, содержащему несколько
репликационных серверов. Данная возможность лежит в основе построения иерархических систем
репликации.
По умолчанию репликационный сервер сохраняет смысл операций. Это значит, что удаление
записи из первичной таблицы (выполнение оператора DELETE) приведет к выполнению такого же
оператора DELETE в узле, хранящем копию таблицы; выполнение INSERT или UPDATE над
первичной таблицей точно так же приведет соответственно к добавлению или обновлению записи
в копии таблицы в результате работы системы репликации.
Имеется гибкий механизм
конфигурирования так называемых функциональных строк (function strings), которые
переопределяют любую операцию на макроязыке с возможностью подстановки параметров.
В одной базе данных могут содержаться как первичные данные, так и данные-копии. Приложение-
клиент, работающее со своей СУБД, может вносить изменения напрямую (операторами INSERT,
DELETE, UPDATE) только в первичные данные. Для изменения копии данных предназначен
механизм асинхронного вызова процедур.
Для работы механизма асинхронного вызова процедур в нескольких базах данных создаются
процедуры с одинаковым именем и параметрами, но, возможно, с различным текстом. В одной
базе данных процедура помечается как предназначенная к репликации. Вызов этой процедуры
вместе со значениями параметров передается через журнал и механизм репликации к узлам-
подписчикам. Затем в базах данных подписчиков вызывается одноименная процедура с теми же
значениями параметров.
Таким образом, для обновления "чужих" для узла данных (копии данных) прикладная программа-
клиент вместо выполнения оператора UPDATE вызывает заранее определенную в этом узле
хранимую процедуру и передает ей параметры (например, значение первичного ключа и новые
значения для обновляемых колонок). Тело этой процедуры пустое и она не выполняет никаких
действий, однако ее вызов записывается в журнал. Механизм репликации обеспечивает вызов на
узле, содержащем первичные данные, одноименной процедуры с подстановкой параметров. В теле
этой процедуры может быть записан оператор UPDATE, обновляющий первичные данные. Тот же
механизм репликации передаст изменения в данных узлу, инициировавшему операцию.
Репликационный сервер и Replication Agent реализованы в виде отдельных модулей и могут
выполняться не на том же компьютере, что сервер базы данных. Включение в систему
репликационного сервера практически не оказывает влияние на загрузку сервера первичной базы
данных.
СУБД, хранящая вторичные данные, может быть любой СУБД, доступной через шлюз, в том числе
Oracle, Informix, Ingres, DB2, RMS, ISAM, или даже приложение Open Server.
СУБД, хранящая первичные данные, требует наличия для нее RA. Сейчас RA имеется для Sybase
SQL Server, Oracle, DB2, Sybase SQL Anywhere. Готовятся RA и для других СУБД. Интерфейс RA
открыт и возможно создание RA для нестандартных источников данных.
Некоторые применения тиражирования данных:
- сервер, выполняющий активное обновление данных (OLTP), разгружается
от сложных запросов, связанных с поддержкой принятия решений (DSS);
- консолидация данных от подразделений в центре;
- обмен данными по медленным и/или ненадежным линиях связи;
- поддержание резервной базы данных;
- построение сети равноправных узлов, обменивающихся данными.
Важно, что репликационный сервер тиражирует транзакции, а не отдельные изменения в базе
данных. Метод тиражирования транзакций гарантирует целостность внутри транзакции, и, как
следствие, невозможность нарушения ссылочной целостности. Схема обновления первичных
данных и копий данных исключает возможность возникновения конфликтов (конфликты могут
быть вызваны только неправильным проектированием системы или сбоем).
