Главная | Обратная связь | Поможем написать вашу работу!

Управление распределенными транзакциями

Осуществляется с помощью протокола двух фазной фиксации (2ФФ). Фиксация результатов транзакции выполняется в два этапа:

1. этап голосования;

2. этап принятия решения.

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

Контроллер транзакций – это компонент ядра СУБД, отвечающий за выполнение транзакций, остальные узлы называются участниками транзакции. В обязанности координатора транзакции входит опрос всех участников транзакции: готовы ли они зафиксировать результаты локальных транзакций (субтранзакций). Если хотя бы один из участников потребует отката своей части транзакции или не ответит на запрос в течение установленного тайм-аута, то координатор укажет всем узлам на необходимость отката транзакции. Этим обеспечивается логическая атомарность транзакции. Координатор выполняет протокол 2ФФ последующему алгоритму.

I) 1 Фаза (голосование):

1. Координатор заносит запись begin_commit в системный журнал и обеспечивает ее перенос из буфера в оперативную память

2. Отправляет все участникам команду PREPARE.

3. Координатор ожидает ответов от всех участников в пределах установленного тайм-аута.

II) 2 Фаза (принятие решений)

1. Если участник возвращает сообщение ABORT, координатор помещает в системный журнал запись abort и обеспечивает ее перенос из буфера в оперативную память. Отправляет сообщение GLOBAL_ABORT и ожидает ответа всех участников в пределах установленного тайм-аута.

2. Если участник не отвечает в течение тайм-аута, координатор считает, что участник откатит свою часть транзакции и поступает соответственно.

3. Если участник возвращает сообщение READY_COMMIT, координатор обновляет список участников, приславших ответы.

4. Если положительные ответы прислали все участники, координатор помещает в системный журнал в системный журнал запись commit и обеспечивает ее перенос из буфера в оперативную память. Отправляет всем участникам сообщение GLOBAL_COMMIT и ожидает ответов всех участников в пределах установленного тайм-аута.

5. После поступления подтверждения о фиксации от всех участников, в журнал помещается запись end_transaction и обеспечивается ее перенос из буфера в оперативную память.

6. Если некоторые узлы не прислали подтверждение фиксации, координатор направляет им сообщения о принятом решении и поступает по этой схеме, до получения всех требуемых подтверждений.

Алгоритм участника транзакции

1. При поступлении команды PREPARE, в том случае, если он готов зафиксировать свою часть транзакции, он помещает запись ready_commit в файл журнала транзакций и отправляет координатору сообщение READY_COMMIT. Если он не может зафиксировать свою часть транзакции, он помещает запись abort в файл журнала транзакций, отправляет координатору сообщение ABORT и откатывает свою часть транзакции (не дожидаясь общего сигнала GLOBAL_ABORT).

2. Если участник отправил координатору сообщение READY_COMMIT, то он ожидает ответа от координатора в пределах установленного тайм-аута.

3. При получении GLOBAL_ABORT участник помещает abort в файл журнала транзакции и отправляет координатору подтверждение отката.

4. При получении GLOBAL_COMMIT участник помещает запись commit в файл журнала транзакций, фиксирует свою часть транзакции и отправляет координатору подтверждение фиксации.

5. Если в течение установленного тайм-аута участник не получается сообщения от координатора, он откатывает свою часть транзакции.

INITIAL

WAITING

DECIDED

COMPLITED

INITIAL

DECIDED

COMPLITED

PREPARED

Отправлена команда prepare

Отправлена команда Global decision

Получено подтверждение

Получена команда prepare

Отправлена команда abort

Получено подтверждения

Рисунок 4 – Диаграмма состояния координатора и участника транзакции

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

· тайм-аут в состоянии WAITING: координатор не может зафиксировать транзакцию, так как не получены все подтверждения от участников о фиксации; ликвидация заключается в откате транзакций;

· тайм-аут в состоянии DECIDED: координатор повторно рассылает сведения о принятом глобально решении и ждет ответов от участников.

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

· тайм-аут в состоянии INITIAL: если не приходит команда PREPARE, то участник не может сообщить о принятом решении координатору, а, следовательно, не может зафиксировать транзакцию, однако он может откатить транзакцию; если участник после тайм-аута (после отката локальной транзакции) получит команду PREPARE, он может проигнорировать ее или отправить координатору сообщение ABORT;

· тайм-аут в состоянии PREPARE: участник известил координатора о принятом им решении и он не может его изменить; если это решение было откатить локальную транзакцию, то он выполняет ее, не дожидаясь ответа от координатора, и поэтому не входит в состояние ожидания; зафиксировать транзакцию участник не может до получения глобального решения, таким образом, участник оказывается заблокированным.

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

При использовании этого протокола, если все участники транзакции установили, что произошел отказ координатора, они могут выбрать нового координатора и завершить транзакцию, выполнив ее откат под управлением нового координатора. Один из протоколов выбора нового координатора основан на упорядочении всех узлов, причем первым в этой цепочке стоит координатор. Все узлы знают свои идентификаторы и номера других узлов. Каждый узел S_i начинает отправлять сообщения узлам: S_i₊₁, S_i₊₂ и т.д. Если узел S_k получает сообщение от узла с меньшим номером, то понимает, что он не может быть новым координатором и заканчивает пересылку сообщений. Таким образом, рано или поздно каждый из участников узнает – существует ли в системе узел с меньшим номером. Если такого узла нет, узел принимает решение стать координатором. Если вновь избранный узел – координатор снова попадает в состояние тайм-аута, протокол выбора запускается снова.

Действия, который выполняются на отказавшем узле, после его перезагрузки, называются протоколом восстановления. Эти действия зависят от того, в каком состоянии находился узел, когда произошел сбой и какую роль выполнял этот узел, в момент отказа: роль координатора или участника. В случае отказа координатора:

1. Состояние INITIAL: процедура 2ФФ еще не запускалась, поэтому после перезагрузки узла следует ее запустить.

2. Состояние WAITING: координатор уже направил команду PREPARE, но еще не получил всех ответов от всех участников, не получил не одного сообщения ABORT, в этом случае координатор перезапускает процедуру 2ФФ.

3. Состояние DECIDED: координатор уже отправил участникам глобальное решение, и, если координатор после своего перезапуска получает все подтверждения, то транзакция считается успешно зафиксированной, в противном случае он должен запустить протокол ликвидации.

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

1. Состояние INITIAL: участник не успел сообщить о своем решении координатору и может выполнить откат.

2. Состояние PREPARED: участник отправил сведения о своем решении координатору, поэтому он должен запустить протокол ликвидации.

3. Состояние ABORTED/COMMITED: в этом состоянии участник уже завершил обработку своей части транзакции, поэтому никаких дополнительных действий не требуется.

⇐ Предыдущая 123 4 Следующая ⇒

Воспользуйтесь поиском по сайту: