Что 3PC сделает в таком сценарии?

Мы используем 3PC (трехфазное обязательство) для распределенной транзакции. Есть 4 узла, A, B, C, D, где A - координатор.

  1. A получил OK от всех остальных и отправил им сообщение о подготовке к фиксации.
  2. Пока C и D получили это сообщение и перешли в подготовленное состояние, B вылетает и не получает это сообщение (таким образом, оставаясь в состоянии ожидания).
  3. Таймаут на B и отправляет прерывание всем остальным, но только D получает сообщение прерывания, в то время как C аварийно завершает работу до получения сообщения прерывания.

Теперь вопрос: что будет делать C после восстановления? Согласно http://courses.cs.vt.edu/~cs5204/fall00/distributedDBMS/sreenu/3pc.html, C будет выполнять фиксацию при восстановлении после перехода отказа вместо прерывания, как это делает D. Не приведет ли это к противоречивому состоянию? Или у C есть какой-то механизм для определения того, что транзакция прервана?


distributed-transactions
person cntswj    schedule 18.07.2017    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

Я ожидаю, что узел C будет прерван, поскольку ему будет приказано это сделать. Думаю, это будет похоже на 2PC. Координатор должен периодически проверять, доступны ли снова потерянные узлы. Когда C перезапускается, координатор может увидеть это и подтолкнуть узел к откату, поскольку сообщение об отмене будет отправлено повторно.

person chalda    schedule 19.07.2017
comment
Извините за опечатку. В последнем абзаце я заменил B на C. Не уверен, продолжит ли координатор проверять C и повторно отправлять сообщение после его восстановления. - person cntswj; 20.07.2017
comment
Я понимаю вашу точку зрения и не знал, как ее выразить по-другому. Теперь я нашел статью researchgate.net/publication/275154978_Three-Phase_Commit. Я бы процитировал оттуда: обратите внимание, что восстанавливающийся участник не может зафиксировать транзакцию, даже если участник находится в состоянии предварительной фиксации по отношению к транзакции. Это связано с тем, что сайты операции все могли решить прервать транзакцию после того, как участник потерпел неудачу, если ни один из них не находился в состоянии перед фиксацией. В этом случае участник должен узнать у других сайтов окончательный статус транзакции. - person chalda; 03.08.2017
comment
Дело в том, что C выздоравливает. C может найти состояние, ожидая команды координатора. Или он может попросить другого участника понять конечное состояние. Это зависит от реализации. - person chalda; 03.08.2017
comment
Похоже, 3PC не поддерживает все виды многоточечных отказов ... как описано в stackoverflow.com/questions/21424962/. - person cntswj; 07.09.2017
comment
С моей точки зрения вы правы. Сам 3PC (как протокол) не способен разрешить эту ситуацию. Но реализация 3PC должна учитывать состояние и возможность правильно завершить транзакцию. - person chalda; 08.09.2017