Репликация

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

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

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

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

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

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

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

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

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

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

2) Менеджеры сайтов – хранителей копий фрагментов БД, m_j. Множество этих менеджеров обозначим 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.

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

routine M