Взаимодействие компонентов репликации данных приведено на рисунке 15.

Рисунок 15. Модель репликации в СУБД ЛИНТЕР

В системе асинхронной репликации участвуют два или более ЛИНТЕР-серверов, на каждом из которых работает:

Объектами репликации являются таблицы БД, список которых вместе с правилами и адресами рассылки хранится в БД-источнике репликации.

БД может быть только приемником, только источником или одновременно и источником и приемником данных репликации. На одном сервере может быть запущено несколько серверов репликации для разных БД.

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

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

Сервер репликации приемника, получает данные от сервера репликации источника и помещает их в приемную очередь (таблица БД репликации).

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

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

Есть три модели поведения системы при возникновении рассогласования между значениями записей в БД реплицируемых серверов. Если такая ситуация возникла во время выполнения операции корректировки/удаления данных, можно предпринять следующие действия:

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

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

При необходимости администратор системы репликации может очистить очереди сервера репликации, при этом будут удалены все уже реплицированные записи, или только записи за указанный период.

Управление асинхронной репликацией в среде UNIX выполняется с помощью командного файла или специальных скриптов, а в среде Windows может выполняться как с помощью командного файла, так и с помощью сервисных средств СУБД ЛИНТЕР.