Как двухфазные фиксации предотвращают провал последней секунды?

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

Что предотвращает следующий сбой?

Все узлы отвечают, что они готов к фиксации
Сделка координатор говорит им: "Продолжайте и совершить ", но один из узлов сбой перед получением этого сообщение
Все остальные узлы успешно выполняются, но теперь распределенная транзакция повреждена.
Я понимаю, что когда сбой node вернется, его транзакция будет отменена (так как она никогда не получала сообщение о фиксации)

Я предполагаю, что каждый node работает с нормальной базой данных, которая ничего не знает о распределенных транзакциях. Что я пропустил?

Ответ 1

Обобщая все ответы:

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

Ответ 2

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

Поскольку node положительно реагировал на фазу "подготовить", он должен иметь возможность "совершать", даже когда он возвращается из-за сбоя.

Ответ 3

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

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

Ответ 4

Двухфазная фиксация не является надежной и предназначена для работы в 99% случаев.

"В протоколе предполагается, что на каждом node существует стабильное хранилище с журналом с записью, что no node навсегда сработает, что данные в журнале с записью никогда не теряются или не повреждаются при сбое, и что любые два узла могут взаимодействовать друг с другом".

http://en.wikipedia.org/wiki/Two-phase_commit_protocol

Ответ 5

Существует множество способов атаковать проблемы с двухфазным фиксацией. Почти все они заканчиваются как вариант алгоритма трехфазного фиксации Paxos. Майк Берроуз, который разработал услугу Chubby lock в Google, основанную на Paxos, сказал, что в лекции, которую я видел, есть два типа алгоритмов распределенного коммита - "Paxos и неправильные".

Одна вещь, с которой столкнулся node, может, когда она пробуждается, говорит: "Я никогда не слышал об этой транзакции, если бы она была совершена?" координатору, который скажет ему, что такое голосование.

Имейте в виду, что это пример более общей проблемы: разбитый node может пропустить многие транзакции до их восстановления. Поэтому очень важно, чтобы после выздоровления он должен был поговорить либо с координатором, либо с другой репликой, прежде чем сделать себя доступным. Если сам node не может сказать, разбился ли он, то все становится все более привлекательным, но все же сговорчивым.

Если вы используете систему кворума для чтения базы данных, несогласованность будет замаскирована (и известна самой базе данных).