Под репликацией понимается создание копий некоторых фрагментов отношений и одновременное хранение нескольких копий на разных сайтах (в разных локальных БД). Репликация используется для того, чтобы «приблизить» данные с «чужого» сайта к месту их использования. Распределенные запросы позволяют пользователю, находящемуся на сайте i, выполнять приложения с данными, находящимися как на сайте i, так и на сайтах j, k, l, … Однако, каждый такой запрос удаленных данных требует очень большого (по сравнению с местным запросом) времени. Если предполагается выполнение большого количества удаленных запросов, то более выгодным оказывается предварительно переместить (скопировать) необходимые фрагменты локальных баз данных с сайтов j, k, l, … на сайт i. Подобное решение используется и при разработке архитектуры аппаратной части компьютеров. Там оно называется кэшированием.
Репликация способствует и повышению надежности хранения данных, поскольку одни и те же данные хранятся в разных местах. Репликация особенно важна для тех сайтов, которые работают в режиме повышенной нагрузки, с большим количеством входящих запросов. Она позволяет снизить нагрузку на эти сайты за счет возможного распараллеливания.
Репликация приводит и к определенным трудностям. Локальные БД постоянно обновляются. В них поступают новые данные, старые данные могут исключаться. Это приводит к тому, что БД(t) ¹ БД(t + Dt) через некоторый период времени Dt. Следовательно, копия БД(t) становится не актуальной, и ее использование может привести к ошибочным результатам запросов.
Выход может состоять в том, чтобы одновременно с локальной базой данных обновлять и все копии этой БД или ее фрагментов.
Применяются синхронные и асинхронные репликации.
Наилучшей с точки зрения актуальности копий является синхронная репликация. При этом все обновления (исходной базы и копий) производятся как часть одной транзакции обновления, т.е. практически одновременно. Во всяком случае, обновление исходной базы не считается завершенным, пока не произведены изменения в копиях.
При асинхронной репликации изменения проводятся сначала в исходной БД, а вслед за этим, возможно, через значительный период времени – в копиях, т.е. какое-то время данные остаются не согласованными.
Для проведения синхронной репликации можно использовать следующий алгоритм (протокол) двухфазной фиксации транзакций.
Исполнители алгоритма:
1) Менеджер сайта – владельца исходной БД (обозначим его M).
2) Менеджеры сайтов – хранителей копий фрагментов БД, mj . Множество этих менеджеров обозначим S.
Состояния исполнителей:
Множество состояний менеджера M имеет вид QM = {инициализация, ожидание, обновление, завершено}.
Множества состояний менеджеров mj имеют одинаковый вид Qm = {инициализация, готов, не готов, выполнено}. Но каждый менеджер имеет свой экземпляр этого множества.
Операции, выполняемые менеджерами.
Менеджер M выполняет следующий набор операций:
1) start – начать транзакцию;
2) send – послать сообщения менеджерам mj ;
3) write – записать информацию в свой журнал;
Менеджеры mj выполняют следующий набор операций:
1) send – послать сообщения менеджеру M;
2) write – записать информацию в свой журнал;
3) put – поместить результаты транзакции в свою копию БД.
Для нашей задачи структуру связей между исполнителями алгоритма можно описать как звезду star(M, S) с центральной вершиной M и множеством периферийных вершин S.
Протокол двухфазной фиксации транзакций состоит из взаимодействующих путем передачи сообщений алгоритмов (рутин) отдельных исполнителей. Здесь приведен упрощенный вариант протокола.
routine M