Почему транзакция XA для распределенной транзакции
Многие СУБД используют специальный протокол 2PC под названием «XA» для распределенных транзакций. Зачем кому-то использовать XA? Для меня XA не может ничего гарантировать в случае сбоя:
В XA Transaction Manager (TM) скажет всем СУБД подготовиться на этапе первый, и, если все они готовы, TM скажет всем им выполнить фиксацию на этапе второй, в противном случае, если какой-либо из них потерпит неудачу, TM сообщит остальные откатить.
Если все СУБД подготовлены на первом этапе, что, если кто-то не выполнит коммит на втором этапе? В этом случае вся транзакция завершится неудачно, а все остальные должны будут откатиться (3-я фаза?), делая первую фазу бессмысленной. То есть первая фаза не может дать никаких гарантий, даже если говорят, что все СУБД подготовлены (хотя она и увеличивает вероятность успеха).
В любом случае ваше предположение неверно, распределенные транзакции требуют, чтобы подготовка была достаточной для успешного выполнения фиксации, в противном случае ресурс не может должным образом участвовать в распределенных транзакциях. Проблемой может быть только недоступность ресурса (но тогда должен быть способ восстановления, чтобы фиксация могла быть выполнена в конечном итоге).
@MarkRotteveel Отредактировано.
Ответы 1
Хотя ваш вопрос кажется скорее теоретическим, чем практическим, но
ты прав (от https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html)
If there is an unexpected halt while the server is in the middle of executing an XA PREPARE, XA COMMIT, XA ROLLBACK, or XA COMMIT ... ONE PHASE statement, the server might not be able to recover to a correct state, leaving the server and the binary log in an inconsistent state.
Но - это о MySQL и пометил этот вопрос этим :)
Если хотите копнуть глубже, думаю, вам стоит перейти на https://dba.stackexchange.com/
Пожалуйста, сосредоточьтесь на одном вопросе. Ваш текущий вопрос немного расплывчатый и слишком общий; также заголовок вашего вопроса, похоже, не охватывает его суть: приведите их в соответствие.