Он состоит из следующих фаз.
1. Фаза подготовки (этап голосования).
Координатор рассылает всем участникам запрос о готовности субтранзакций к фиксации. Ожидание ответа происходит в пределах некоторого установленного таймаута. На этом же этапе выполняется копирование данных из буферов на диск, но в журнал транзакций не добавляется запись о завершении, и блокировки не снимаются.
2. Фаза фиксирования (этап принятия решения).
Если в течение таймаута какой-либо узел не пришлет ответ или потребует отката своей субтранзакции, координатор разошлет широковещательное сообщение с требованием отката всех субтранзакций. Если же все узлы готовы зафиксировать свои изменения, посылается команда с требованием выполнить фиксацию. После этого считается, что распределенная транзакция успешно завершена.
9.4. Репликация данных
Большое значение в крупных разветвленных организациях имеет быстрая рассылка важной информации от одних филиалов к другим, от филиалов к центральному офису, от центрального офиса к филиалам и т. п. Совокупность механизмов СУРБД, обеспечивающих отображение изменений данных с одного сервера на другие серверы называется репликацией.
Репликация бывает синхронной и асинхронной. При синхронной репликации обновления всех копий данных производятся субтранзакциями, входящими в состав одной распределенной транзакции. Копии обновляются одновременно с обновлением оригинала и, как правило, с использованием двухфазной фиксации. Следует заметить, что распределенная транзакция не считается успешно завершенной, если один из серверов с копией реплицируемых данных не доступен.
Асинхронная репликация предполагает создание копий с запаздыванием, т. е. через некоторое время после обновления основной базы данных.
При этом некоторые локальные СУБД наделяются правом владения данными, т. е. привилегиями по их обновлению. Широко распространены следующие три схемы владения.
1. Схема «ведущий/ведомый».
Данная схема предполагает, что в сети имеется, по меньшей мере, один узел, имеющий право на обновление реплицируемых данных. Такой узел называется ведущим (первичным) узлом, или издателем. Узлы, не владеющие данными, являются ведомыми; они на них располагаются копии реплицируемых данных, доступные только для чтения. Ведомые узлы называют подписчиками: они подписываются на данные, предоставляемые издателем.
В схеме «ведущий/ведомый» можно выделить два способа репликации.
1.1. Распространение информации (рис. 9.2).
Рисунок 9.2 – Распространение информации
Данные обновляются в центральном звене системы, которое является издателем. Затем происходит репликация: множество подписчиков получает копии данных. В качестве примера можно привести процесс рассылки прайс-листа: прайс-лист подготавливается на одном, центральном узле, а затем рассылается на удаленные узлы.
1.2. Консолидация информации (рис. 9.3).
Рисунок 9.3 – Консолидация информации
Здесь имеются несколько издателей, автономно владеющих разными частями распределенной БД. Обновленный фрагмент БД реплицируется на центральный узел-подписчик. Таким образом, центральный узел содержит общее хранилище, доступное только для чтения. В качестве примера консолидации можно привести распространение информации о проданных билетах на поезда: первоначально сведения о продаже билетов поступают в локальные хранилища информации, территориально расположенные в различных населенных пунктах, затем, спустя короткий промежуток времени, – передаются в общее, централизованное хранилище, откуда и становятся общедоступными для множества локальных СУБД в разных населенных пунктах.
В реальной жизни распространение и консолидация смешиваются: узел-издатель может «оформить подписку» на данные другого узла-издателя, т. е. одновременно участвовать в распространении и консолидации.
2. Схема «рабочий поток».
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.