Инструменты пользователя

Инструменты сайта


examination:rsubd:question17

Вопрос №17. Проблема управления восстановлением

Управление восстановлением

Управление восстановлением в распределенных системах обычно базируется на протоколе двухфазной фиксации транзакций (или некоторых его вариантах). Двухфазная фиксация транзакций требуется в любой среде, где отдельная транзакция может взаимодействовать с несколькими автономными диспетчерами ресурсов. Однако в распределенных системах ее использование приобретает особую важность, поскольку рассматриваемые диспетчеры ресурсов, т.е. локальные СУБД, функционируют на отдельных узлах и поэтому в значительной мере автономны. Рассмотрим некоторые особенности этого процесса, описанные ниже.

  • Принцип «отсутствия зависимости от центрального узла» предписывает, что функции координатора не должны назначаться одному выделенному узлу в сети, а должны выполняться на различных узлах для различных транзакций. Обычно управление транзакцией передается на тот узел, на котором она была инициирована. Поэтому каждый узел (как правило) должен быть способен выполнять функции координатора для некоторых транзакций и выступать в качестве участника выполнения остальных транзакций.
  • Для двухфазной фиксации транзакций координатор должен взаимодействовать с каждым участвующим узлом, что подразумевает увеличение количества сообщений, а значит, дополнительную нагрузку на коммуникации.
  • Если узел Y является участником транзакции, выполняемой по протоколу двух фазной фиксации и координируемой узлом X, узел Y должен делать то, что предписывает ему узел X (фиксацию результатов транзакции или ее откат в зависимости от того, что именно потребуется), а это означает потерю (хотя и относительно не значительную) локальной автономности.

Рассмотрим повторно процесс двухфазной фиксации транзакций. Обратимся к рис. 4, на котором показано взаимодействие между координатором и обычным участником.


Рис. 4. Двухфазная фиксация транзакции

Для общности предположим, что координатор и участник находятся на разных узлах, кроме того, на данном рисунке ось времени направлена слева направо (но иногда временная последовательность нарушается). К тому же для упрощения предположим, что в транзакции затребовано выполнение операции COMMIT, а не ROLLBACK. После получения запроса на операцию COMMIT координатор организует следующий описанный ниже двухфазный процесс.

  • Каждому участнику координатор отдает распоряжение «приготовиться к фиксации или откату» транзакции. На рис. 4 показано сообщение «приготовиться», отправленное в момент t1 и полученное участником в момент t2. Далее участник принудительно помещает запись в журнал локального агента из своего физического журнала, а затем выдает координатору подтверждение «ОК». Безусловно, если возникнет какая-либо ошибка (в частности, если произойдет сбой в работе локального агента), будет передано сообщение «Not OK». На рисунке это сообщение, которое для простоты обозначено как «ОК», отправлено в момент t3 и получено координатором в момент t4. Как уже отмечалось выше, участник теперь теряет автономность: он должен делать то, что ему будет предписывать координатор. Кроме того, любые ресурсы, которые заблокированы локальным агентом, должны оставаться заблокированными до тех пор, пока участник не получит и не выполнит распоряжение координатора.
  • После получения подтверждения от всех участников координатор принимает решение либо зафиксировать транзакцию, если все ответы были «ОК», либо выполнить откат транзакции в противном случае. Затем в момент t5 координатор вносит в свой физический журнал запись о принятом решении. Время t5 служит границей между первой и второй фазами фиксации транзакции.
  • Будем считать, что было принято решение о фиксации транзакции. В этом случае координатор отдаст распоряжение всем участникам «выполнить», т.е. запустить обработку операции фиксации для локального агента. На рис. 4 показано сообщение «выполнить», отправленное в момент t6 и полученное участником в момент t7. Участник выполняет операцию фиксации для локального агента и отправляет подтверждение «выполнено» координатору. На рисунке подтверждение отправлено координатору в момент t8 и получено координатором в момент t9.
  • После того как координатором будут получены все подтверждения, процесс полностью завершается.

На практике, безусловно, этот процесс в целом значительно сложнее, чем описано выше, поскольку необходимо еще позаботиться о возможных отказах узла или сети, которые могут произойти в любой момент. Предположим, например, что на узле координатора сбой произошел в некоторый момент t между отметками времени t5 и t6. В процессе восстановления работы узла процедура повторного пуска обнаружит в журнале сведения о том, что в момент отказа некоторая транзакция находилась на второй фазе двухфазного процесса фиксации, после чего процесс будет продолжен, начиная с отправки участникам сообщений «выполнить». Отметим, что в период от t3 до t7 участник находится в состоянии «отсутствия определенной информации» о состоянии транзакции. Если произойдет отказ узла координатора в момент t, как указано выше, период «отсутствия определенной информации» может оказаться достаточно длительным.

Теоретически, безусловно, было бы желательно, чтобы процесс двухфазной фиксации оказался устойчивым к любым возможным сбоям. К сожалению, несложно понять, что эта цель, по сути, недостижима, т.е. не существует какого-либо конечного протокола, который бы гарантировал, что все участники одновременно зафиксируют успешно завершившуюся транзакцию или одновременно ее отменят, столкнувшись при выполнении с некоторым отказом. Предположим обратное, что такой протокол существует. Пусть N – минимальное количество сообщений, которые требуются для работы подобного протокола. Теперь допустим, что последнее из этих N сообщений утеряно из-за сбоев. Тогда или это сообщение не было необходимым, а это противоречит предположению о том, что N – минимальное количество сообщений, или протокол в такой ситуации работать не будет. И в том, и в другом случае возникает противоречие, из которого следует, что такого протокола не существует.

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

  • Во-первых, если агент на некотором конкретном узле участника выполняет операции только чтения, такой участник при завершении первой фазы процесса может ответить «игнорируйте мое присутствие» и координатор действительно может игнорировать такого участника во второй фазе процесса.
  • Во-вторых, если все участники в первой фазе процесса ответят «игнорируйте мое присутствие», вторая фаза может быть полностью пропущена.
  • И в-третьих, существует два важных варианта основной схемы, которые называются вариантами предполагаемой фиксации и предполагаемого отката, соответственно, которые будут далее описаны более подробно.

В общем случае в результате применения схем предполагаемой фиксации и предполагаемого отката сокращается количество передаваемых сообщений, как в случае успешного завершения (для предполагаемой фиксации), так и в случае отказа (для предполагаемого отката). Прежде чем приступить к объяснению действия этих двух схем, отметим, что основной механизм, как описано выше, требует, чтобы координатор помнил о своем решении, пока не получит подтверждения от каждого участника. Причина, очевидно, заключается в том, что если произойдет отказ узла какого-либо из участников в период «отсутствия определенной информации о транзакции», то при перезапуске он будет вынужден вновь отослать координатору запрос, чтобы узнать, каково же было решение координатора в отношении данной транзакции. Но как только все подтверждения будут получены, координатор будет считать, что все участники выполнили то, что им было предписано, и поэтому он может «забыть» о данной транзакции.

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

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

Любопытно отметить (что в определенной степени противоречит здравому смыслу), что метод предполагаемого отката кажется более предпочтительным по сравнению со схемой предполагаемой фиксации (это противоречит здравому смыслу, поскольку, безусловно, большинство транзакций завершаются успешно, а схемой предполагаемой фиксации ограничивается количество сообщений именно в случае успеха). Проблема, связанная со схемой предполагаемой фиксации, состоит в следующем. Предположим, что на узле координатора сбой произошел во время первой фазы, т.е. до принятия решения. После перезапуска узла координатора данная транзакция будет отменена, поскольку она не завершена. Следовательно, некоторые участники будут запрашивать координатора о его решении относительно данной транзакции. Координатор такой транзакции не помнит, поэтому предполагается решение «зафиксировать», что, конечно же, неверно.

Чтобы избежать такой «ложной фиксации», координатор (использующий схему предполагаемой фиксации) должен в начале первой фазы поместить в свой физический журнал запись, содержащую список всех участников данной транзакции. (Если теперь на узле координатора произойдет сбой во время первой фазы фиксации транзакции, то после его перезапуска он сможет передать всем участникам сообщение «выполнить откат»). А такая необходимость выполнения физической операции ввода-вывода при обращении к журналу координатора создает критический путь в процессе выполнения каждой транзакции. Поэтому схема предполагаемой фиксации не так заманчива, как может показаться на первый взгляд.

examination/rsubd/question17.txt · Последние изменения: 2014/01/15 12:21 (внешнее изменение)