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

Question

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

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

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

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

Answer 1

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

<Ол>

Нельзя использовать обычные базы данных с распределенными транзакциями. База данных должна явно поддерживать координатора транзакций.

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

Answer 2

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

Поскольку узел ответил положительно в " prepare " на этапе необходимо иметь возможность «фиксировать», даже когда он возвращается после сбоя.

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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