Aсинхронная репликация

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

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

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

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

В частности, конфликты могут возникать по поводу того, в каком порядке должны применяться обновления. Например, предположим, что в результате выполнения транзакции А происходит вставка строки в реплику X, после чего транзакция B удаляет эту строку, а также допустим, что Y — реплика X. Если обновления распространяются на Y, но вводятся в реплику Y в обратном порядке (например, из-за разных задержек при передаче), то транзакция B не находит в Y строку, подлежащую удалению, и не выполняет своё действие, после чего транзакция А вставляет эту строку! Суммарный эффект состоит в том, что реплика Y содержит указанную строку, а реплика X — нет.

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

3. По способу передачи информации во время процесса репликации.

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

4. По способу анализа реплицируемой информации.

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

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

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

5. По времени проведения сеанса репликации.

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

Репликация предоставляет следующие возможности:

· автоматизированное и надежное перемещение изменений данных из одной системы в другую (позволяет автоматически вносить изменения при появлении их в источнике);

· создание идентичных копий в двух системах (например, поддержка второй копии данных для их восстановления);

· копирование подмножества данных из одной системы во многие (например, с целью синхронизации информации в разных системах). Такой вид репликации называется распределением данных;

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

Описание решения

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

1. В таких системах, как «1С бухгалтерия», изменения могут происходить на разных копиях БД. Поэтому репликация требуется мульти-направленная.

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

3. Чтобы не перегружать сервера, выбираем асинхронную репликацию.

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

Сформируем модель приложения:

Так как базы будут разнородные, но с идентичными схемами, контролировать придется только изменения данных. Причем синхронизировать будем отдельные таблицы. Следовательно, приложение должно иметь инструмент-сервис, регулярно выполняющий синхронизацию, и инструмент для отложенной синхронизации, который должен включать возможности выставления настроек подключения (host, port, username, password, database, table) для каждой базы данных. В каждой синхронизируемой базе должен быть лог транзакций (таблица, в которой при помощи триггерных процедур фиксируются все изменения).