15.3.8.3 Restrictions on XA Transactions — MySQL 9.2

15.3.8.3 Ограничения для XA-транзакций

Поддержка XA-транзакций ограничена движком хранения InnoDB.

Для “внешнего XA” сервер MySQL выступает в роли менеджера ресурсов, а клиентские программы — в роли менеджеров транзакций. Для “внутреннего XA” движки хранения внутри сервера MySQL действуют как менеджеры ресурсов (RM), а сам сервер — как менеджер транзакций (TM). Поддержка внутреннего XA ограничена возможностями отдельных движков хранения. Внутреннее XA необходимо для обработки XA-транзакций, которые включают более одного движка хранения. Реализация внутреннего XA требует, чтобы движок хранения поддерживал двухфазный фиксацию на уровне обработчика таблиц, и в настоящее время это выполняется только для InnoDB.

Для XA START указываемые в запросе JOIN и RESUME определяются, но не влияют на результат.

Для XA END определяется оператор SUSPEND [FOR MIGRATE], но не оказывает никакого влияния.

Требование, чтобы часть bqual значения xid была различной для каждой XA-транзакции в рамках глобальной транзакции, является ограничением текущей реализации MySQL XA. Это не часть спецификации XA.

XA-транзакция записывается в двоичный журнал в двух частях. Когда выполняется XA PREPARE, первая часть транзакции до XA PREPARE записывается с использованием начального GTID. Для идентификации таких транзакций в двоичном журнале используется XA_prepare_log_event. Когда выполняется XA COMMIT или XA ROLLBACK, вторая часть транзакции, содержащая только оператор XA COMMIT или XA ROLLBACK, записывается с использованием второго GTID. Обратите внимание, что начальная часть транзакции, идентифицируемая как XA_prepare_log_event, необязательно сопровождается её XA COMMIT или XA ROLLBACK, что может привести к интерливированному двоичному протоколированию любых двух XA-транзакций. Две части XA-транзакции могут даже появиться в разных файлах двоичного журнала. Это означает, что XA-транзакция в состоянии PREPARED теперь остается постоянной до явного выполнения оператора XA COMMIT или XA ROLLBACK, гарантируя совместимость XA-транзакций с репликацией.

На реплике сразу после подготовки XA-транзакции она отделяется от потока приложения репликации, и может быть подтверждена или отменена любым потоком на реплике. Это означает, что одна и та же XA-транзакция может отображаться в таблице events_transactions_current с разными состояниями в разных потоках. Таблица events_transactions_current отображает текущий статус последнего отслеживаемого события транзакции в потоке и не обновляет этот статус, когда поток неактивен. Таким образом, XA-транзакция может по-прежнему отображаться в состоянии PREPARED для исходного потока приложения репликации после её обработки другим потоком. Для достоверной идентификации XA-транзакций, которые всё ещё находятся в состоянии PREPARED и требуют восстановления, используйте оператор XA RECOVER, а не таблицы транзакций Performance Schema.

Существуют следующие ограничения при использовании XA-транзакций:

Использование фильтров репликации или фильтров двоичного журнала в сочетании с XA-транзакциями не поддерживается. Фильтрация таблиц может привести к тому, что XA-транзакция станет пустой на реплике, а пустые XA-транзакции не поддерживаются. Кроме того, при использовании хранилища метаданных подключения реплики и хранилища метаданных приложения реплики, хранящихся в таблицах InnoDB (по умолчанию), внутреннее состояние транзакции движка данных изменяется после отфильтрованной XA-транзакции и может стать несовместимым с состоянием контекста транзакции репликации.

Ошибка регистрируется всякий раз, когда XA-транзакция затрагивается фильтром репликации, независимо от того, была ли транзакция пустой в результате. Если транзакция не пустая, реплика может продолжить работу, но следует принять меры по прекращению использования фильтров репликации с XA-транзакциями, чтобы избежать потенциальных проблем. Если транзакция пустая, реплика останавливается. В этом случае реплика может оказаться в неопределённом состоянии, в котором согласованность процесса репликации может быть нарушена. В частности, gtid_executed на реплике реплики может быть несовместима с таковой на источнике. Для решения этой ситуации изолируйте источник и остановите всю репликацию, затем проверьте согласованность GTID по всей топологии репликации. Отмените XA-транзакцию, которая сгенерировала сообщение об ошибке, затем перезапустите репликацию.
XA-транзакции считаются небезопасными для репликации на основе операторов. Если две XA-транзакции, подтвержденные параллельно на источнике, готовятся на реплике в обратном порядке, могут возникнуть зависимости блокировок, которые нельзя безопасно разрешить, и репликация может завершиться ошибкой с тупиком на реплике. Такая ситуация может возникнуть как для однопоточной, так и для многопоточной реплики. При установке параметра binlog_format=STATEMENT выдаётся предупреждение для операторов DML внутри XA-транзакций. При установке binlog_format=MIXED или binlog_format=ROW операторы DML внутри XA-транзакций регистрируются с помощью репликации на основе строк, и потенциальная проблема отсутствует.
Следует учитывать, что при последовательном использовании одного и того же идентификатора транзакции (XID) для выполнения XA-транзакций и возникновении прерывания во время обработки оператора XA COMMIT ... ONE PHASE, синхронизация состояния между двоичным журналом и движком хранения может больше не быть возможной. Это может произойти, если описанная серия событий произошла после подготовки этой транзакции в движке хранения, в то время как оператор XA COMMIT всё ещё выполняется. Это известная проблема.