4. Распределенные базы данных

4. Распределенные базы данных
Под распределенной базой данных (РБД) понимается набор логически
связанных между собой разделяемых данных, которые физически распределены по
разных узлам компьютерной сети.
СУРБД – это программный комплекс (СУБД), предназначенный для управления
РБД и позволяющий сделать распределенность прозрачной для конечного
пользователя. Прозрачность РБД заключается в том, что с точки зрения конечного
пользователя она должна вести себя точно также, как централизованная.
Логически единая БД разделяется на фрагменты, каждый из которых хранится
на одном компьютере, а все компьютеры соединены линиями связи. Каждый из этих
фрагментов работает под управлением своей СУБД.
Пример топологии РБД приведен на рис. 4.1.
Узел1
Узел2
БД2
Сеть
БД1
Узел3
Узел4
Рис. 4.1. Пример топологии РБД
Пользователи взаимодействуют с РБД через приложения (локальные или
глобальные). Глобальные приложения обращаются к данным на других узлах сети, а
локальные – нет. В РБД должно быть хотя бы одно глобальное приложение.
4.1. Критерии распределенности (по К. Дейту)
На настоящий момент существует большое количество различных СУБД,
претендующих на то, чтобы называться распределёнными, хотя в полном объёме
распределенность не реализована ни в одной из них. В 1987 г. К. Дейт выделил 12
правил построения СУРБД, опираясь на которые можно определить степень
соответствия конкретной СУБД требованиям распределенности.
1. Локальная автономность. Она заключается в следующем:
 Локальные данные принадлежат локальным узлам и управляется
администраторами локальных БД.
 Локальные процессы в РБД остаются локальными.
 Все процессы на локальном узле контролируются только этим узлом.
2. Отсутствие опоры на центральный узел.
В системе не должно быть узла, без которого система не может функционировать,
т.е. не должно быть центральных служб, например, управления транзакциями или
блокировками.
3. Непрерывное функционирование.
Удаление или добавление узла не должно требовать остановки системы в целом.
4. Независимость от местоположения.
Пользователь должен получать доступ к любым данным в системе, независимо от
того, являются эти данные локальными или удалёнными.
5. Независимость от фрагментации.
Доступ к данным не должен зависеть от наличия или отсутствия фрагментации и от
типа фрагментации.
6. Независимость от репликации.
Доступ к данным не должен зависеть от наличия или отсутствия реплик данных.
Сведения о репликах являются внутренней информацией системы и используются
для определения наиболее оптимального способа доступа к данным.
7. Обработка распределенных запросов.
Распределённым считается запрос, обращающийся более чем к одному узлу (т.е. к
данным, расположенным на двух и более узлах). Система должна автоматически
определять методы выполнения соединения (объединения) данных, сетевой канал,
способный справиться с объёмом передаваемой информации, и узел, имеющий
достаточную вычислительную мощность для соединения таблиц.
8. Обработка распределенных транзакций.
Протокол обработки распределённой транзакции должен обеспечивать выполнение
четырёх основных свойств транзакции: атомарность, согласованность,
изолированность и продолжительность. Если в транзакции участвуют более одного
узла, этот протокол позволит ей завершиться только в том случае, когда каждый
узел выполнит поставленные задачи. Если хотя бы один узел не может выполнить
свою задачу, вся транзакция должна быть отменена.
9. Независимость от типа оборудования.
СУРБД
должна
функционировать
на
оборудовании
с
различными
вычислительными платформами.
10. Независимость от операционной системы.
СУРБД должна функционировать под управлением различных операционных
систем.
11. Независимость от сетевой архитектуры.
СУРБД должна быть способной функционировать в сетях с различной архитектурой
и типами носителя.
12. Независимость от типа СУБД.
СУРБД должна быть способной функционировать поверх различных локальных
СУБД, возможно, с различными моделями данных (требование гетерогенности).
РБД, в узлах которой работают однотипные СУБД, называется гомогенной РБД.
Если же СУБД в узлах сети поддерживают разные модели данных, то такая РБД
называется гетерогенной.
Последние четыре требования на практике реализуются только частично. Т.е. развитые
СУРБД предоставляют возможность поддерживать несколько платформ, несколько
операционных систем, несколько сетевых архитектур и несколько семейств СУБД.
4.2. Методы поддержки распределенных данных
Существуют различные методы поддержки распределенности:
1. Фрагментация.
2. Репликация.
3. Распределенные запросы.
4. Распределенные транзакции.
5. Распределенные ограничения целостности.
4.2.1. Фрагментация данных
Фрагментация – это разбиение базы данных на фрагменты и размещение их по
разным узлам сети. Фрагментация является основным способом организации РБД. Она
позволяет хранить данные на том узле, где они наиболее часто используются.
Основные проблемы, которые при этом возникают – это прозрачность написания
запросов к данным и, возможно, поддержка распределенных ограничений целостности.
Фрагментации могут подвергаться не только база данных в целом, но и отдельные
отношения БД.
Схема фрагментации отношения должна удовлетворять трем условиям:
1. Полнота: если отношение R разбивается на фрагменты R1, R2,…, Rn, то URi = R
(Каждый кортеж должен входить хотя бы в один фрагмент).
2. Восстановимость: должна существовать операция реляционной алгебры,
позволяющая восстановить отношение R из его фрагментов. Это правило
гарантирует сохранение функциональных зависимостей.
3. Непересекаемость: если элемент данных dj  Ri, то он не должен присутствовать
одновременно в других фрагментах. Исключение составляет первичный ключ при
вертикальной фрагментации. Это правило гарантирует минимальную избыточность
данных.
Существуют два основных типа фрагментации отношений: горизонтальная и
вертикальная. Горизонтальный фрагмент является результатом селекции (selection)
(рис. 4.2,а), а вертикальный – результатом проекции (projection) (рис. 4.2,б).
E1
E2
E1
E2
E3
E3
а)
б)
Рис. 4.2. Примеры (а) горизонтальной и (б) вертикальной фрагментации
Горизонтальная фрагментация может быть использована в тех случаях, когда
отношение целесообразно разделить по значению одного или нескольких атрибутов.
Например, если сведения о сотрудниках каждого из трех филиалов компании имеет
смысл хранить в данном филиале, то отношение "Сотрудники" (Emp) может быть
разбито следующим образом:
E1 = σdep=1(Emp)
E2 = σdep=2(Emp)
E3 = σdep=3(Emp)
Горизонтальная фрагментация удовлетворяет всем условиям корректности
фрагментации.
Вертикальная фрагментация обычно применяется в тех случаях, когда часть
атрибутов отношения используется в одном узле, а часть – в другом. Например, если
отношение "Сотрудники" (Emp) содержит такие поля, как:
Emp ( tabNo,
// табельный номер
fname,
// фамилия
lname,
// имя
post,
// должность
sex,
// пол
born,
// дата рождения
tel,
// телефон
address,
// адрес
dep,
// номер отдела (филиала)
polis,
// номер страхового полиса
salary)
// оклад
и для отдела кадров требуются поля (tabNo, fname, lname, tel, address, dep), а для
бухгалтерии – поля (tabNo, post, sex, born, polis, salary), то это отношение может быть
разбито следующим образом:
S1 = π(tabNo, fname, lname, tel, address, dep)(Emp)
S2 = π(tabNo, post, sex, born, polis, salary)(Emp)
Вертикальная фрагментация удовлетворяет всем условиям корректности
фрагментации, кроме условия непересекаемости для значений атрибутов первичного
ключа, который должен присутствовать во всех фрагментах.
На основании двух основных типов вводят еще два типа фрагментации:
смешанную (рис. 4.3) и производную, которая является вариантом горизонтальной
фрагментации.
E2
E1
E3
E4
Рис. 4.3. Пример смешанной (гибридной) фрагментации
В качестве примера смешанной фрагментации можно объединить два
предыдущих примера: в вертикальной фрагментации S1, S2 добавить условие хранения
личной информации о сотрудниках в том филиале, в котором этот сотрудник работает:
S1 = π(tabNo, fname, lname, tel, address, dep)(Emp)
S11 = σdep=1(S1)
S12 = σdep=2(S1)
S13 = σdep=3(S1)
S2 = π(tabNo, post, sex, born, polis, salary)(Emp)
Для смешанной фрагментация также выполняются условия корректности.
Производная фрагментация строится для подчиненного отношения на основе
фрагментов родительского отношения. Например, для фрагментов S1i подчиненное
отношение "Дети" (Child), информацию о которых также целесообразно хранить в
соответствующих узлах, имеет смысл разбить на три горизонтальных фрагмента:
C1 = C ►tabNo S11
C2 = C ►tabNo S12
C3 = C ►tabNo S13
где символ ► обозначает естественное полусоединение отношения C и фрагмента S1i
(включает кортежи отношения С, которые могут быть соединены с соответствующим
кортежем фрагмента S1i по значению внешнего ключа).
Если подчиненное отношение включает более одного внешнего ключа, то для
производной фрагментации приходится делать выбор в пользу одного из них.
4.2.2. Репликация данных
Репликация – это поддержание двух и более идентичных копий (реплик) данных
на разных узлах РБД. Реплика может включать всю базу данных (полная репликация),
одно или несколько взаимосвязанных отношений или фрагмент отношения. Также
возможен вариант с консолидацией данных, при котором каждый узел владеет своей
частью данных (например, отношения) и может ее обновлять, а на одном из узлов РБД
эти
части
соединяются
(или
объединяются)
вместе
для
образования
консолидированной копии "только для чтения" (read only).
К основным достоинствам механизма репликации можно отнести повышение
доступности и надежности данных и повышение локализации ссылок на
реплицируемые данные. Основным недостатком репликации является сложность
поддержания идентичности реплик: если в одну копию данных вносятся изменения, то
эти изменения также должны быть внесены в другие копии. Это называется
распространение изменений и реализуется службой тиражирования.
Служба тиражирования должна выполнять следующие функции:
1. Обеспечение масштабируемости, т.е. эффективная обработки больших и малых
объемов данных.
2. Преобразование типов и моделей данных (для гетерогенных РБД).
3. Репликация объектов БД, например, индексов, триггеров и т.п.
4. Инициализация вновь создаваемой реплики.
5. Обеспечение возможности "подписаться" на существующие реплики, чтобы
получать их в определенной периодичностью.
Для выполнения этих функций в языке, поддерживаемом СУБД, предусматривается
наличие средств определения схемы репликации, механизма подписки и механизма
инициализации реплик (создания и заполнения данными).
Существуют различные подходы к организации репликации:
 Репликация с основной копией. Существуют следующие варианты:
1. Классический подход заключается в наличии одной основной копии, в которую
можно вносить изменения; остальные копии создаются с определением read
only.
2. Асимметричная репликация: основная копия фрагментирована и распределена
по разным узлам РБД, и другие узлы могут являться подписчиками отдельных
фрагментов (read only).
3. Рабочий поток. При использовании этого подхода право обновления не
принадлежит постоянно одной копии, а переходит от одной копии в другой в
соответствии с потоком операций. В каждый момент времени обновляться
может только одна копия. Например, при последовательной обработке заказов
на поставку товаров сначала в отделе приема заказ принимается, затем на складе
определяют, может ли он быть выполнен и сколько это будет стоить, затем эти
данные передаются в финансовый отдел, а после оплаты – в отдел доставки. При
репликации данных из узла Si на узел Si+1 вместе с новыми данными передается
право на обновление реплики.
 Симметричная репликация (без основной копии). Все копии реплицируемого
набора могут обновляться одновременно и независимо друг от друга, но все
изменения одной копии должны попасть во все остальные копии.
Существует два основных механизма распространения изменений при
симметричной репликации:
– синхронный: изменения во все копии вносятся в рамках одной транзакции;
– асинхронный: подразумевает отложенный характер внесения изменений в
удаленные копии.
Достоинствами синхронного распространения изменений являются полная
согласованность копий и отсутствие конфликтов обновления. К недостаткам следует
отнести трудоемкость и большую длительность модификации данных и низкую
надежность работы системы: при выходе из строя одного узла все копии становятся
недоступны для внесения изменений.
При использовании асинхронного режима распространения изменений могут
возникать конфликты обновления. Можно выделить следующие конфликтные
ситуации:
1. Добавление двух записей с одинаковыми первичными или уникальными ключами.
Для предотвращения таких ситуаций обычно каждому узлу РБД выделяется свой
диапазон значений ключевых (уникальных) полей.
2. Конфликты удаления: одна транзакция пытается удалить запись, которая в другой
копии уже удалена другой транзакцией. Если такая ситуация считается конфликтом,
то она разрешаются вручную.
3. Конфликты обновления: две транзакции в разных копиях обновили одну и ту же
запись, возможно, по-разному, и пытаются распространить свои изменения. Для
идентификации конфликтов обновления необходимо передавать с транзакцией
дополнительную информацию: старое и новое содержимое записи. Если старая
запись не может быть обнаружена, налицо конфликт обновления.
Для разрешения конфликтов обновления применяются различные методы,
например:
1) Разрешение по приоритету узлов: для каждого узла назначается приоритет, и к
записи применяется обновление, поступившее с узла с максимальным приоритетом.
2) Разрешение по временной отметке: все транзакции имеют временную отметку, и к
записи применяется обновление с минимальной или максимальной отметкой.
Использовать ли для этого минимальную или максимальную отметку – зависит от
предметной области и, обычно, может регулироваться.
3) Аддитивный метод (add – добавить): может применяться в тех случаях, когда
изменения основаны на предыдущем значении поля, например, salary = salary + X.
При этом к значению поля последовательно применяются все обновления.
4) Использование пользовательских процедур.
5) Разрешение конфликтов вручную. Сведения о конфликте записываются в журнал
ошибок для последующего анализа и устранения администратором.
Для настройки реакции на конфликты некоторые СУБД позволяют выделить в каждой
таблице столбец (группу столбцов), и описать для них способ разрешения конфликтов
(т.н. группа обновления).
Существуют различные варианты реализации распространения изменений. Один
из них заключается в использовании триггеров. Напомним, что триггеры – это
процедуры, которые срабатывают при наступлении определенных событий (например,
insert, delete, update). Внутрь триггера помещаются команды, проводящие на других
копиях обновления, аналогичные тем, которые вызвали выполнение триггера. Этот
подход достаточно гибкий, но он обладает рядом недостатков:
– триггеры создают дополнительную нагрузку на систему;
– триггеры не могут выполняться по графику (время срабатывания триггера не
определено);
– с помощью триггеров сложнее организовать групповое обновление связанных
таблиц (из-за проблемы мутирующих таблиц).
Другой способ реализации механизма распространения изменений – поддержка
журналов изменений для реплицируемых данных. Рассылка этих изменений входит в
задачу сервера СУБД или сервера тиражирования (входящего в состав СУБД).
Основные принципы, которых необходимо придерживаться при этом:
1. Для сохранения согласованности данных должен соблюдаться порядок внесения
изменений.
2. Информация об изменениях должна сохраняться в журнале до тех пор, пока не
будут обновлены все копии этих данных.
4.2.3. Распределенные запросы
Распределенным называется запрос, который обращается к двум и более узлам
РБД, но не обновляет на них данные. Запрашивающий узел должен определить, что в
запросе идет обращение к данным на другом узле, выделить подзапрос к удаленному
узлу и перенаправить его этому узлу.
Самой сложной проблемой выполнения распределенных запросов является
оптимизация, т.е. поиск оптимального плана выполнения запроса. Информация,
которая требуется для оптимизации запроса, распределена по узлам. Если выбрать
центральный узел, который соберет эту информацию, построит оптимальный план и
отправит его на выполнение, то теряется свойство локальной автономности. Поэтому
обычно распределенный запрос выполняется так: запрашивающий узел собирает все
данные, полученные в результате выполнения подзапросов, у себя, и выполняет их
соединение (или объединение), что может занять очень много времени.
4.2.4. Распределенные транзакции
Распределенные транзакции обращаются к двум и более узлам и обновляют на
них данные. Основная проблема распределенных транзакций – соблюдение логической
целостности данных. Транзакция на всех узлах должна завершиться одинаково: или
фиксацией, или откатом. Выполнение распределенных транзакций осуществляется с
помощью специального алгоритма, который называется двухфазная фиксация
(подробнее об управлении распределенными транзакциями см. ниже).
4.2.5. Распределенные ограничения целостности
Распределенные ограничения целостности возникают тогда, когда для проверки
соблюдения какого-либо ограничения целостности системе необходимо обратиться к
другому узлу. Например, база данных разделена на фрагменты таким образом, что
родительская таблица находится на одном узле, а дочерняя, связанная с ней по
внешнему ключу, – на другом. При добавлении записи в дочернюю таблицу система
обратится к узлу, на котором расположена родительская таблица, для проверки наличия
соответствующего значения ключа. Или случай разбиения одной таблицы на
фрагменты и размещение этих фрагментов по разным узлам сети. Здесь будет
необходима проверка соблюдения ограничения первичного ключа.
4.3. Методы распределения данных
Определение и размещение фрагментов БД на узлах сети должно проводиться с
учетом особенностей использования БД. Эмпирически установлено, что в большинстве
БД 20% запросов создают 80% нагрузки на БД. Эти запросы и нужно анализировать
для того, чтобы определить целесообразное разбиение БД на фрагменты и размещение
этих фрагментов.
При анализе БД с целью определения схемы размещения по узлам учитывают:
1) Количественные показатели (в первую очередь, объем данных): они влияют на
размещение данных.
2) Качественные показатели: они определяют схему фрагментации. При этом, обычно,
учитываются следующие параметры:
– частота запуска приложений;
– узел, на котором запускается приложение;
– требования к производительности транзакций и приложений;
– требования к времени реакции системы за запросы и т.д.
Критерии, по которым производится определение и размещение фрагментов БД:
1. Локальность ссылок.
2. Повышение надежности и доступности (репликация).
3. Производительность (наличие "узких" мест или неэффективное использование
ресурсов системы).
4. Баланс между ёмкостью и стоимостью внешней памяти.
5. Минимизация расходов на передачу данных.
Существует
три
вида
распределения
данных
(как
альтернатива
централизованному размещению данных):
1. Фрагментированное размещение. База данных разбивается на множество
непересекающихся фрагментов, каждый из которых хранится на отдельном узле.
Каждый фрагмент размещается на том узле, где он чаще всего используется: это
обеспечивает высокий уровень локальности ссылок.
2. Размещение с полной репликацией. На каждом узле размещается полная копия
(реплика) всей базы данных.
3. Выборочная репликация. Этот метод является комбинацией двух предыдущих и
централизованного размещения. На фрагменты делятся данные, используемые
только на отдельных узлах. Реплицируются данные, не подверженные частым
изменениям. Остальные данные хранятся централизовано. Данный метод
использует все преимущества методов и позволяет исключить их недостатки (при
правильном проектировании РБД).
В табл. 1 приведены сравнительные характеристики различных стратегий
распределения данных.
Таблица 1. Сравнительные характеристики различных стратегий распределения данных
Виды
Характеристики
размещения локальнадежность,
производи- стоимость
затраты на
ность
доступность
тельность
хранения
передачу
ссылок
данных
Централизосамая
самые низкие
неудовл.
самая
самые высокие
ванное
низкая
низкая
Фрагменти- высокая1 низкие для отд. удовлетвосамая
низкие1
1
рованное
элементов, вы- рительная
низкая
сокие в целом
для системы (*)
Полная
самая
самые высокие
хорошая
самая
высокие для
репликация
высокая
для чтения
высокая
обновления,
низкие для
чтения
1
Выборочная высокая
(*)
удовлетвосредняя
низкие1
1
репликация
рительная
1
Обеспечивается при условии качественного проектирования.
Как видно из таблицы, метод выборочный репликации, который потенциально
имеет самые высокие показатели, предъявляет и самые высокие требования к качеству
проектирования.
4.4. Управление распределенными транзакциями
Управление распределенными транзакциями осуществляется с помощью
протокола двухфазной фиксации (2ФФ).
Фиксация результатов транзакции выполняется в два этапа: этап голосования и
этап принятия решения. Выполнение этого протокола контролируется координатором
транзакции, роль которого обычно выполняет контроллер транзакций того узла,
который инициирует данную транзакцию. (Контроллер транзакций – это компонент
ядра СУБД, который отвечает за выполнение транзакций). Остальные узлы, на которых
выполняется транзакция, называются участниками транзакции. В обязанности
координатора транзакции входит опрос всех участников транзакции, готовы ли они
зафиксировать результаты локальных субтранзакций. Если хотя бы один из участников
потребует отката своей части транзакции или не ответит на запрос в течение
установленного тайм-аута, то координатор укажет всем узлам на необходимость отката
всей транзакции. Таким образом обеспечивается логическая атомарность транзакции.
Координатор выполняет протокол 2ФФ по следующему алгоритму:
I. Фаза 1 (голосование).
1. Координатор заносит запись begin_commit в системный журнал и обеспечивает ее
перенос из буфера в ОП на ВЗУ.
2. Отправляет всем участникам команду PREPARE.
3. Ожидает ответов всех участников в пределах установленного тайм-аута.
II. Фаза 2 (принятие решения).
4. Если участник возвращает сообщение ABORT, координатор помещает в системный
журнал запись abort и обеспечивает ее перенос из буфера в ОП на ВЗУ; отправляет
всем участникам сообщение GLOBAL_ABORT и ожидает ответов всех участников
в пределах установленного тайм-аута.
5. Если участник не отвечает в течение установленного тайм-аута, координатор
считает, что данный участник откатит свою часть транзакции и поступает
соответственно.
6. Если участник возвращает сообщение READY_COMMIT, координатор обновляет
список участников, приславших ответы.
7. Если положительные ответы прислали все участники, координатор помещает в
системный журнал запись commit и обеспечивает ее перенос из буфера в ОП на
ВЗУ. Отправляет всем участникам сообщение GLOBAL_COMMIT и ожидает
ответов всех участников в пределах установленного тайм-аута.
8. После поступления подтверждений о фиксации от всех участников помещает в
системный журнал запись end_transaction и обеспечивает ее перенос из буфера в
ОП на ВЗУ.
9. Если некоторые узлы не прислали подтверждения фиксации, координатор заново
направляет им сообщения о принятом решении и поступает по этой схеме до
получения всех требуемых подтверждений.
Участник транзакции действует по следующему алгоритму:
1. При получении команды PREPARE, в том случае, если он готов зафиксировать
свою часть транзакции, он помещает запись ready_commit в файл журнала
транзакций и отправляет координатору сообщение READY_COMMIT. Если он не
может зафиксировать свою часть транзакции, он помещает запись abort в файл
журнала транзакций, отправляет координатору сообщение ABORT и откатывает
свою часть транзакции (не дожидаясь общего сигнала GLOBAL_ABORT).
2. Если участник отправил координатору сообщение READY_COMMIT, то он
ожидает ответа координатора в пределах установленного тайм-аута.
3. При получении GLOBAL_ABORT участник помещает запись abort в файл журнала
транзакций, откатывает свою часть транзакции и отправляет координатору
подтверждение отката.
4. При получении GLOBAL_COMMIT участник помещает запись commit в файл
журнала транзакций, фиксирует свою часть транзакции и отправляет координатору
подтверждение фиксации.
5. Если в течение установленного тайм-аута участник не получает сообщения от
координатора, он откатывает свою часть транзакции.
Диаграммы состояния координатора и участников транзакции представлены на рис. 4.4.
Если координатор (или участник) не получает в течение установленного таймаута ожидаемого сообщения, то на соответствующем узле запускается протокол
ликвидации. (Состояние тайм-аута на рис. 4.4 отмечено темным фоном.)
Протокол ликвидации для координатора:
1. Тайм-аут в состоянии WAITING: координатор не может зафиксировать транзакцию,
потому что не получены все подтверждения от участников о фиксации. Ликвидация
заключается в откате транзакции.
2. Тайм-аут в состоянии DECIDED: координатор повторно рассылает сведения и
принятом глобальном решении и ждет ответов от участников.
Простейший протокол ликвидации для участника заключается в блокировании
процесса до тех пор, пока сеанс связи с координатором не будет восстановлен. Но в
целях повышения производительности (и автономности) узлов могут быть
предприняты и другие действия:
INITIAL
Отправлена команда
Prepare
WAITING
Отправлена команда
Global decision
DECIDED
Получены
подтверждения
COMPLITED
а)
INITIAL
Получена
команда
Prepare
PREPARED
Отправлена
команда
Abort
Получены
подтверждения
DECIDED
COMPLITED
б)
Рис. 4.4. Диаграммы состояния координатора и участника транзакции
1. Тайм-аут в состоянии INITIAL: если не приходит команда PREPARE, то участник
не может сообщить о своем решении координатору и не может зафиксировать
транзакцию. Но он может предпринять действий по откату транзакции. Если он
позднее (после истечения тайм-аута и отката локальной транзакции) получит
команду PREPARE, он может проигнорировать ее или отправить координатору
сообщение ABORT.
2. Тайм-аут в состоянии PREPARED: участник уже известил координатор о принятом
им решении и он не может его изменить. (Если это решение – откатить локальную
часть транзакции, то он выполняет ее не дожидаясь ответа от координатора и
поэтому не входит в состояние ожидания). Но зафиксировать транзакцию он не
может
до
получения
глобального
решения.
Участник
оказывается
заблокированным.
Один из возможных вариантов решения этой проблемы заключается в
использовании кооперативного протокола ликвидации: участник запрашивает
других участников транзакции о принятом глобальном решении. Простейший способ
информировать участников о том, какие еще узлы участвуют в транзакции – передать
вместе с командой PREPARE список всех участников. При использовании этого
протокола, если все участники транзакции установили, что произошел отказ
координатора, они могут выбрать нового координатора и закончить транзакцию,
выполнив ее откат под управлением нового координатора.
Один из протоколов выбора нового координатора основан на упорядочении всех
узлов, причем первым в этой цепочке стоит координатор. Все узлы знают свои
идентификаторы и номера других узлов. Каждый узел Si начинает отправлять
сообщения узам Si+1, Si+2 ,…, причем именно в таком порядке. Если узел Sk получает
сообщение от узла с меньшим номером, он понимает, что не может быть новым
координатором, и прекращает пересылку сообщений. Рано или поздно каждый из
участников узнает, существует ли в системе узел в меньшим номером. Если его нет,
узел принимает решение стать новым координатором. Если вновь избранный
координатор опять попадает в состояние тайм-аута, протокол выбора запускается
снова.
Действия, которые выполняются на отказавшем узле после его перезагрузки,
называются протоколом восстановления. Они зависят от того, в каком состоянии
находился узел, когда произошел сбой, и какую роль выполнял этот узел в момент
отказа: координатора или участника.
При отказе координатора:
1. В состоянии INITIAL: процедура 2ФФ еще не запускалась, поэтому после
перезагрузки следует ее запустить.
2. В состоянии WAITING: координатор уже направил команду PREPARE, но еще не
получил всех ответов и не получил ни одного сообщения ABORT. В этом случае он
перезапускает процедуру 2ФФ.
3. В состоянии DECIDED: координатор уже направил участникам глобальное
решение. Если после перезапуска он получит все подтверждения, то транзакция
считается успешно зафиксированной. В противном случае он должен прибегнуть к
протоколу ликвидации.
При отказе участника цель протокола восстановления – гарантировать, что
после восстановления узел выполнит в отношении транзакции то же действие, которое
выполнили другие участники, и сделает это независимо от координатора, т.е. по
возможности без дополнительных подтверждений. Рассмотрим три возможных
момента возникновения отказа:
1. В состоянии INITIAL: участник еще не успел сообщит о своем решении
координатору, поэтому он может выполнить откат, т.к. координатор не мог принять
решение о глобальной фиксации транзакции без голоса этого участника.
2. В состоянии PREPARED: участник уже направил сведения о своем решении
координатору, поэтому он должен запустить свой протокол ликвидации.
3. В состоянии ABORTED/COMMITED: участник уже завершил обработку своей
части транзакции, поэтому никаких дополнительных действий не требуется.
Существуют различные подходы к реализации протокола 2ФФ. На рис. 4.5,а
приведена схема обмена сообщениями между координатором и участниками при
традиционной реализации, подразумевающая передачу 4N сообщений, где N –
количество участников.
Линейная схема приведена на рис. 4.5,б. В соответствие с этой схемой
координатор отправляет команду PREPARE (вместе со списком участников) только
одному участнику, а тот в свою очередь передает ее "по цепочке" другим участникам,
дополняя ее своим решением (ABORT или COMMIT). Последний в цепочке участник
отправляет обратно сообщение об общем решении (GLOBAL_ABORT или
GLOBAL_COMMIT). Количество передаваемых сообщений в этой схеме уменьшается
до 2N, но снижается параллельность выполнения транзакции, т.к. каждый участник
должен ждать получения общего решения "по цепочке". Повышения эффективности
данной схемы можно добиться, если обязать последнего в цепочке участника рассылать
широковещательное сообщение об общем решении всем участникам транзакции.
Существует также распределенный способ реализации протокола 2ФФ
(рис. 4.5,в). Все узлы, получив от координатора команду PREPARE, рассылают всем
участникам сведения о своем решении. Как только узел получает все подтверждения
готовности к фиксации, он может фиксировать свою часть транзакции. Если он
получает хотя бы одно сообщение ABORT, он откатывает транзакцию. Фаза принятия
решения при этом отсутствует.
а)
Участник 1
Участник 1
КоордиКоордиA/RC натор GC/GA
…
натор PREPARE …
Участник N
C/A
Координатор
Участник N
фаза голосования
фаза принятия решения
б)
PREPARE
Координатор
Prepare+C/A
Участник 1
GC/GA
Prepare+C/A
Участник 2
GC/GA
…
Участник N
GC/GA
в)
Координатор
Участник i
Участник 1
Участник N
Рис. 4.5. Схемы реализации протокола 2ФФ
Протокол 2ФФ не является не блокирующим, но на практике вероятность
появления этой блокировки очень мала. Поэтому данный протокол используется в
большинстве СУБД.