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

Question

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

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

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

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

Answer 1

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

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

Answer 2

Обобщая ответы каждого:

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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