Введение в системы БД (542480), страница 205
Текст из файла (страница 205)
Двухфазная фиксация транзакций требуется в любой среде, где отдельная транзакция может взаимодействовать с несколькими автономными менеджерами ресурсов. Однако в распределенных системах ее использование приобретает исключительную важность, поскольку рассматриваемые менеджеры ресурсов, т.е. локальные СУБД, функционируют на отдельных узлах и поэтому в значительной мере автономны.
Рассмотрим некоторые особенности этого процесса. 1. Принцип "Отсутствие опоры на центральный узел" предписывает, что функции координатора не должны назначаться одному выделенному узлу в сети, а должны выполняться на различных узлах для различных транзакций. Обычно управление транзакцией передается на тот узел, на котором она была инициирована. Поэтому каждый узел должен быть способен выполнять функции координатора для некоторых транзакций и выступать в качестве участника выполнения остальных транзакций.
2. Для двухфазной фиксации транзакций координатор должен взаимодействовать с каждым участвующим узлом, что подразумевает повышенный уровень обмена сообщениями, создающий дополнительную нагрузку на коммуникации. З За исключением того, что моментальные снимки предполагается использовать лишь для чтения (не считая периодического обновления), в то время как некоторые коммерческие системы разрешают пользователям обновлять "дубликаты" непосредственно (см., наприиер, (20 2122 Конечно, данная возможность также противоречит независимости репликаяии. 787 Глава 20.
Распределенные базы данных 3. Если узел Х является участником транзакции, выполняемой по протоколу двухфазной фиксации и коордннируемой узлом Х, узел Х должен делать то, что предписывает ему узел Х гфиксацию результатов транзакции или ее откат в зависимости от того, что именно потребуется), а это означает потерю (хотя и относительно незначительную) локальной независимости. Давайте повторно рассмотрим процесс двухфазной фиксации транзакций, описанный ранее, в главе !4. Обратимся к рис. 20.5, на котором показано взаимодействие между координатором и обычным участником (будем считать его для простоты удаленным узлом). Рис. 20.5.
Двухфазная фиксацил транзакции Время на этом рисунке идет слева направо (более илн менее!). Будем считать для простоты, что для рассматриваемых транзакций выполняется операция СОИИ1Т, а не ВОЬЬВАСК. После получения запроса на операцию СОИИ1Т координатор организует следующий двухфазный процесс. ° Каждому участнику координатор отдает распоряжение "приготовиться к фиксации или откату" транзакции.
На рис. 20.5 показано сообщение "приготовиться", отосланное в момент с1 и полученное участником в момент с2. Далее участник принудительно помешает запись в журнал локального агента из своего физического журнала, а затем выдает координатору подтверждение "ОК". Конечно, если возникнет какая-либо ошибка (в частности, если произойдет сбой локального агента), будет отослано сообщение "Ног ОК". На рисунке это сообщение, которое для простоты обозначено как "ОК", переслано в момент 03 и получено координатором в момент ~4. Как уже отмечалось выше, участник теперь теряет независимость: он должен делать то, что ему будет предписывать координатор.
Кроме того, любые ресурсы, которые заблокированы локальным агентом, должны оставаться заблокированными до тех пор, пока участник, получивший распоряжение координатора, его не выполнит. ° После получения подтверждения ото всех участников координатор принимает решение либо зафиксировать транзакцию, если все ответы — "ОК", либо выполнить откат транзакции в противном случае.
Затем в момент 05 координатор добавляет в журнал запись о своем решении. Время с5 служит границей между первой и второй фазами фиксации транзакции. 788 Часть 'г. Дополнительные аспекты ° Будем считать, что было принято решение о фиксации транзакции. В этом случае координатор отдаст распоряжение всем участникам "выполнить", т.е. запустить обработку операции фиксации для локального агента. На рис. 20.5 показано сообщение "выполнить", отосланное в момент с6 и полученное участником в момент ~7. Участник выполняет операцию фиксации для локального агента и отсылает подтверждение "выполнено" координатору.
На рисунке сообщение отослано координатору в момент 16 и получено в момент с9. ° После того как координатором будут получены все подтверждения, процесс будет полностью завершен. На практике, конечно, этот процесс, в целом, значительно сложнее, чем описано выше, поскольку необходимо еще позаботиться о возможных отказах узла илн каналов связи. Предположим, например, что на узле координатора сбой произошел в некоторый момент с между отметками времени 15 и с6. В процессе восстановления работы узла процедура повторного пуска обнаружит в журнале сведения о том, что в момент отказа некоторая транзакция была во второй фазе двухфазного процесса фиксации, после чего процесс будет продолжен, начиная с пересылки участникам сообщений "выполнить".
Отметим, что в период от 13 до 17 участник находится в состоянии ожидания завершения транзакции. Если координатор попал в аварийную ситуацию, как указывалось выше, в момент с, период ожидания может оказаться достаточно длительным. Теоретически, конечно, можно было бы считать процесс двухфазной фиксации устойчивым к любым возможным сбоям. К сожалению, несложно понять, что эта задача, по сути, недостижима, т.е. не существует какого-либо конечного протокола, который бы гарантировал, что все участники одновременно зафиксируют успешно завершившуюся транзакцию или одновременно ее отменят, столкнувшись при выполнении с некоторым отказом. Предположим противное, т.е. предположим, что такой протокол существует. Пусть й— минимальное количество сообщений, которые требуются таким протоколом. Предположим, что последнее нз этих 17 сообщений утеряно нз-за сбоев.
Тогда или это сообщение не было необходимым, что противоречит предположению о том, что й — минимальное количество сообщений, или протокол в этой ситуации работать не будет. И в том, и в другом случае получаем противоречие, из которого следует, что такого протокола не существует. Но несмотря на этот удручающий факт существует ряд усовершенствований, которые можно внести в основной алгоритм для повышения его производительности. ° Во-первых, если агент на некотором конкретном узле участника выполняет операции только чтения, такой участник при завершении первой фазы процесса может ответить "игнорируйте меня" и координатор действительно может игнорировать такого участника во второй фазе процесса.
° Во-вторых, если все участники в первой фазе процесса ответят "игнорируйте меня", вторая фаза вообще может быть полностью опущена. ° И в-третьих, существуют два важных варианта основной схемы, которые называются вариантами предполагаемой фиксации и предполагаемого отката соответственно 120.15). Они будут описаны ниже. В общем случае в результате применения схем предполагаемой фиксации и предполагаемого отката сокращается количество передаваемых сообщений как в удачных случаях (для предполагаемой фиксации), так и в случаях отказов (для предполагаемого отката). Глава 20.
Распределенные базы данных 789 Прежде чем приступить к объяснению действия этих двух схем, заметим, что основной механизм, как описано выше, требует, чтобы координатор помнил о своем решении, пока не получит подтверждения от каждого участника. Причина, очевидно, заключается в том, что если некоторый участник попадет в аварийную ситуацию в период ожидания, то при рестарте он будет вынужден вновь отослать координатору запрос, чтобы узнать, каково же было решение координатора в отношении данной транзакции. Однако как только все подтверждения будут получены, координатор будет считать, что все участники выполнили то, что им было предписано, и поэтому он может "забыть*' о данной транзакции.
Рассмотрим теперь схему предполагаемой фиксации. Согласно этой схеме от участников требуется подтверждение сообщений "откатить" ("отменить"), а не сообщений "зафиксировать" ("выполнить"). Поэтому координатор может забыть о транзакции после того, как передаст широковещательное сообщение о своем решении, при условии, что это решение — "зафиксировать*'.
Если в период ожидания подтверждения участник попадает в аварийную ситуацию, в процессе повторного пуска он, как всегда, опросит координатора о состоянии данной транзакции. Если координатор еще помнит о данной транзакции, т.е. еше ожидает подтверждений от ее участников, его решением должно быть "откатить", в противном случае оно должно быть "зафиксировать". Схема предполагаемого отката — это противоположная схема. От участников требуется подтверждение сообщений "зафиксировать", а не сообщений "откатить".
И координатор может забыть о транзакции после того, как передаст широковещательное сообщение о своем решении, если это решение — "откатить". Если участник в период ожидания завершения транзакции попадает в аварийную ситуацию, то в процессе рестарта он должен будет опросить координатора о принятом им решении.
Если координатор еше помнит о данной транзакции, т.е. еше ожидает подтверждений от ее участников, его решением будет "зафиксировать", в противном случае — "откатить". Интересно, и даже как-то противоестественно, что схема предполагаемого отката оказывается более предпочтительной по сравнению со схемой предполагаемой фиксации ("противоестественно", поскольку, несомненно, большинство транзакций зафиксируется успешно, а схемой предполагаемой фиксации ограничивается количество сообщений именно в случае успешной фиксации).
Проблема, связанная со схемой предполагаемой фиксации, состоит в следующем. Предположим, что на узле координатора сбой произошел во время первой фазы, т.е. до принятия решения. После перезапуска узда координатора данная транзакция будет отменена, поскольку она не завершена. Следовательно, некоторые участники будут запрашивать координатора о его решении относительно данной транзакции. Координатор такой транзакции не помнит, поэтому предполагается решение "зафиксировать", что, конечно же, неверно. Чтобы избежать такой "ложной фиксации", координатор (использующий схему предполагаемой фиксации) должен в начале первой фазы поместить в свой физический журнал запись, содержащую список всех участников данной транзакции.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
