Репликация

Под репликацией понимается создание копий некоторых фрагментов отношений и одновременное хранение нескольких копий на разных сайтах (в разных локальных БД). Репликация используется для того, чтобы "приблизить" данные с "чужого" сайта к месту их использования. Распределенные запросы позволяют пользователю, находящемуся на сайте i, выполнять приложения с данными, находящимися как на сайте i, так и на сайтах j, k, l, … Однако, каждый такой запрос удаленных данных требует очень большого (по сравнению с местным запросом) времени. Если предполагается выполнение большого количества удаленных запросов, то более выгодным оказывается предварительно переместить (скопировать) необходимые фрагменты локальных баз данных с сайтов j, k, l, … на сайт i. Подобное решение используется и при разработке архитектуры аппаратной части компьютеров. Там оно называется кэширова нием.

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

Репликация приводит и к определенным трудностям. Локальные БД постоянно обновляются. В них поступают новые данные, старые данные могут исключаться. Это приводит к тому, что БД(t) БД(t + Δ t) через некоторый период времени Δ. Следовательно, копия БД(t) становится не актуальной, и ее использование может привести к ошибочным результатам запросов.

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

Применяются синхронные и асинхронные репликации.

Наилучшей с точки зрения актуальности копий является синхронная репликация. При этом все обновления (исходной базы и копий) производятся как часть одной транзакции обновления, т.е. практически одновременно. Во всяком случае, обновление исходной базы не считается завершенным, пока не произведены изменения в копиях.

При асинхронной репликации изменения проводятся сначала в исходной БД, а вслед за этим, возможно, через значительный период времени – в копиях, т.е. какое-то время данные остаются не согласованными.

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

Исполнители алгоритма:

1. Менеджер сайта – владельца исходной БД (обозначим его M).

2. Менеджеры сайтов – хранителей копий фрагментов БД, mj. Множество этих менеджеров обозначим S.

Состояния исполнителей:

Множество состояний менеджера M имеет вид Q_M = {инициализация, ожидание, обновление, завершено}.

Множества состояний менеджеров m_j имеют одинаковый вид Q_m = {инициализация, готов, не готов, выполнено}. Но каждый менеджер имеет свой экземпляр этого множества.

Операции, выполняемые менеджерами.

Менеджер M выполняет следующий набор операций:

1. start – начать транзакцию;

2. send – послать сообщения менеджерам m_j;

3. write – записать информацию в свой журнал;

Менеджеры m_j выполняют следующий набор операций:

1. send – послать сообщения менеджеру M;

2. write – записать информацию в свой журнал;

3. put – поместить результаты транзакции в свою копию БД.

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

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

Менеджер сайта – владельца исходной базы данных получает сообщение "включить данные в БД" при необходимости корректировки копий. Менеджер заносит соответствующую запись "начало транзакции" в свой журнал, готовит структуру данных (L := ) для занесения в нее в будущем информации о готовности периферийных сайтов и рассылает всем сообщение "приготовиться к изменениям". Кроме этого, менеджер устанавливает предельное время (T) для проведения всего процесса.

Менеджеры m_j сайтов начинают присылать сообщения о своей готовности. Идентификаторы этих сайтов заносятся в множество n. Если все сайты готовы, то при приходе последнего сообщения выполнится условие L = S, т.е. множество сайтов, сообщивших о своей готовности, совпадает с множеством всех сайтов.

После этого менеджер M отправляет всем m_j сообщение "общее обновление". Далее идет процесс, похожий на предыдущий. Только теперь менеджеры m_j проводят обновления и сообщают об этом словом "выполнено". Если все выполнят обновления, то транзакция завершается.

Если какой-либо из сайтов не готов или не выполнил обновление, то менеджер M дает команду "общий возврат", отменяющую транзакцию. После отмены он ожидает подтверждений о принятии отмены от менеджеров копий базы данных.

Переменная "состояние сайта" является" на каждом сайте разделяемой между менеджером копии и другими управляющими программами. Первоначально менеджер копии m_j устанавливает ее значение как "готов". Впоследствии другие управляющие программы могут присваивать ей как значение "готов", так и значение "не готов".

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

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

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