Як двофазні коміти запобігають відмові в останній секунді?

Я вивчаю, як працює двофазне комітування в розподіленій транзакції. Я розумію, що в останній частині фази координатор транзакцій запитує кожен вузол, чи готовий він до фіксації. Якщо всі погодились, то це говорить їм іти далі і робити зобов'язання.

Що запобігає наступному збою?

1. Усі вузли відповідають, що готові до фіксації
2. Координатор транзакцій каже їм "продовжувати і фіксувати", але один з вузлів виходить з ладу перед тим, як отримати це повідомлення
3. Усі інші вузли успішно фіксуються, але тепер розподілена транзакція пошкоджена
4. Я розумію, що коли аварійний вузол повернеться назад, його транзакція буде відкатана (оскільки він ніколи не отримував повідомлення про фіксацію)

Я припускаю, що на кожному вузлі працює звичайна база даних, яка не знає нічого про розподілені транзакції. Що я пропустив?

Ні, вони не отримують вказівки відкочуватись назад, оскільки в оригінальному сценарії плаката деякі вузли вже зафіксовані. Що трапляється, коли аварійний вузол стає доступним, координатор транзакції каже йому, щоб знову здійснити фіксацію.

Оскільки вузол позитивно відреагував на фазі "підготовка", він повинен мати можливість "фіксувати", навіть коли він повертається з аварійного завершення роботи.

Підсумовуючи відповіді всіх:

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

2. Вузли не отримують вказівки відкочуватись назад, оскільки деякі з них вже зафіксовано. Що трапляється, так це те, що коли аварійний вузол повертається, координатор транзакції каже йому завершити коміт.

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

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

Двофазна фіксація не є надійною і просто розроблена для роботи в 99% випадків.

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

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

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

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

Майте на увазі, що це приклад більш загальної проблеми: аварійний вузол може пропустити багато транзакцій, перш ніж він відновиться. Тому надзвичайно важливо, щоб після відновлення він мав поговорити або з координатором, або з іншою копією, перш ніж зробити себе доступним. Якщо сам вузол не може визначити, чи він не вийшов з ладу, то все залучається до більш активного, але все ще відстежуваного.

Якщо ви використовуєте систему кворуму для читання бази даних, невідповідність буде замаскована (і доведена до відома самої бази даних).