13.3.7.3 Restrictions on XA Transactions — MySQL 5.7

13.3.7.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.

До MySQL 5.7.7 XA-транзакции были несовместимы с репликацией. Это происходило потому, что XA-транзакция, находящаяся в состоянии PREPARED, откатывалась при чистой остановке сервера или отключении клиента. Аналогично, XA-транзакция в состоянии PREPARED по-прежнему находилась бы в состоянии PREPARED в случае аварийной остановки и последующего запуска сервера, но содержимое транзакции не могло быть записано в бинарный журнал. В обеих этих ситуациях XA-транзакция не могла быть правильно реплицирована.

В MySQL 5.7.7 и более поздних версиях произошло изменение поведения, и 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-транзакций в MySQL 5.7.7 и более поздних версиях:

XA-транзакции не полностью устойчивы к неожиданной остановке в отношении бинарного журнала. Если произойдёт неожиданная остановка во время выполнения сервером операторов XA PREPARE, XA COMMIT, XA ROLLBACK или XA COMMIT ... ONE PHASE, сервер может не восстановиться в корректное состояние, оставив сервер и бинарный журнал в несогласованном состоянии. В этой ситуации бинарный журнал может содержать дополнительные XA-транзакции, которые не применяются, или пропустить XA-транзакции, которые применяются. Кроме того, если включены GTID, после восстановления @@GLOBAL.GTID_EXECUTED может неверно описывать применённые транзакции. Обратите внимание, что если неожиданная остановка произойдёт до XA PREPARE, между XA PREPARE и XA COMMIT (или XA ROLLBACK), или после XA COMMIT (или XA ROLLBACK), сервер и бинарный журнал будут корректно восстановлены в согласованное состояние.
Использование фильтров репликации или фильтров бинарных журналов в сочетании с XA-транзакциями не поддерживается. Фильтрация таблиц может привести к тому, что XA-транзакция окажется пустой на реплике, а пустые XA-транзакции не поддерживаются. Также, при настройках master_info_repository=TABLE и relay_log_info_repository=TABLE на реплике, которые стали значениями по умолчанию в MySQL 8.0, внутреннее состояние транзакции движка данных изменяется после отфильтрованной XA-транзакции и может стать несогласованным со статусом контекста транзакции репликации.

Ошибка регистрируется всякий раз, когда XA-транзакция затронута фильтром репликации, независимо от того, была ли транзакция пустой в результате. Если транзакция не пустая, реплика может продолжить работу, но вы должны предпринять шаги для прекращения использования фильтров репликации с XA-транзакциями, чтобы избежать потенциальных проблем. Если транзакция пустая, реплика останавливается. В этом случае реплика может оказаться в неопределённом состоянии, в котором может быть нарушена согласованность процесса репликации. В частности, gtid_executed на реплике реплики может не совпадать с таковым на источнике. Для решения этой ситуации изолируйте источник и остановите всю репликацию, затем проверьте согласованность GTID по всей топологии репликации. Отмените XA-транзакцию, которая сгенерировала сообщение об ошибке, затем перезапустите репликацию.
До MySQL 5.7.19 FLUSH TABLES WITH READ LOCK несовместима с XA-транзакциями.
XA-транзакции считаются небезопасными для репликации на основе операторов. Если две XA-транзакции, подтверждённые параллельно на источнике, готовятся на реплике в обратном порядке, могут возникнуть зависимости блокировки, которые нельзя безопасно разрешить, и репликация может завершиться с тупиком на реплике. Эта ситуация может возникнуть для однопоточной или многопоточной реплики. Когда binlog_format=STATEMENT установлена, выдаётся предупреждение для DML-операторов внутри XA-транзакций. Когда binlog_format=MIXED или binlog_format=ROW установлены, DML-операторы внутри XA-транзакций регистрируются с помощью репликации на основе строк, и потенциальная проблема отсутствует.