Documentation Home
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] 条款被承认但没有效力。

全局事务中每个 XA 事务的bqual部分值都不同 的要求是当前 MySQL XA 实现的限制。xid它不是 XA 规范的一部分。

在 MySQL 5.7.7 之前，XA 事务与复制不兼容。这是因为处于 PREPARED状态的 XA 事务将在干净的服务器关闭或客户端断开连接时回滚。同理，一个处于状态的XA事务，在服务器异常关闭再启动的情况下，PREPARED状态仍然存在PREPARED，但是事务的内容无法写入二进制日志。在这两种情况下，都无法正确复制 XA 事务。

在 MySQL 5.7.7 及更高版本中，行为发生了变化，XA 事务分两部分写入二进制日志。发出时 XA PREPARE ，事务的第一部分XA PREPARE使用初始 GTID 写入。AXA_prepare_log_event用于标识二进制日志中的此类事务。当 发出XA COMMITorXA ROLLBACK 时，事务的第二部分仅包含 XA COMMITorXA ROLLBACK 语句，使用第二个 GTID 编写。请注意，由 标识的交易的初始部分 XA_prepare_log_event不一定后跟其XA COMMIT或XA ROLLBACK，这会导致任意两个 XA 事务的交错二进制日志记录。XA 事务的两部分甚至可以出现在不同的二进制日志文件中。这意味着处于PREPARED状态的 XA 事务现在是持久的，直到发出显式XA COMMIT或 XA ROLLBACK语句，确保 XA 事务与复制兼容。

在副本上，在准备好 XA 事务后，它会立即与副本应用程序线程分离，并且可以由副本上的任何线程提交或回滚。这意味着相同的 XA 事务可以 events_transactions_current在不同线程上以不同状态出现在表中。该 events_transactions_current表显示线程上最近监视的事务事件的当前状态，并且在线程空闲时不更新此状态。PREPARED所以 XA 事务在被另一个线程处理后，仍然可以显示为原始应用程序线程的状态。积极识别仍在的 XA 事务PREPAREDstate 并且需要恢复，使用XA RECOVER语句而不是 Performance Schema 事务表。

在 MySQL 5.7.7 及更高版本中使用 XA 事务存在以下限制：

  • 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，服务器和二进制日志将被正确恢复并进入一致状态。

  • The use of replication filters or binary log filters in combination with XA transactions is not supported. Filtering of tables could cause an XA transaction to be empty on a replica, and empty XA transactions are not supported. Also, with the settings master_info_repository=TABLE and relay_log_info_repository=TABLE on a replica, which became the defaults in MySQL 8.0, the internal state of the data engine transaction is changed following a filtered XA transaction, and can become inconsistent with the replication transaction context state.

    ER_XA_REPLICATION_FILTERS每当 XA 事务受到复制过滤器的影响时，都会记录 错误 ，无论事务是否因此为空。如果事务不为空，副本能够继续运行，但您应该采取措施停止对 XA 事务使用复制过滤器以避免潜在问题。如果事务为空，则副本停止。在这种情况下，副本可能处于不确定状态，在这种情况下，复制过程的一致性可能会受到损害。特别是，gtid_executed在副本的副本上设置的可能与源上的设置不一致。要解决这种情况，请隔离源并停止所有复制，然后检查复制拓扑中的 GTID 一致性。撤消生成错误消息的 XA 事务，然后重新启动复制。

  • 在 MySQL 5.7.19 之前，FLUSH TABLES WITH READ LOCK与 XA 事务不兼容。

  • XA 事务被认为对于基于语句的复制是不安全的。如果在源上并行提交的两个 XA 事务正以相反的顺序在副本上准备，则可能会出现无法安全解决的锁定依赖关系，并且复制可能因副本上的死锁而失败。对于单线程或多线程副本，可能会出现这种情况。设置时 binlog_format=STATEMENT，将对 XA 事务内的 DML 语句发出警告。binlog_format=MIXED设置或 时 binlog_format=ROW，XA 事务内的 DML 语句使用基于行的复制进行记录，并且不存在潜在问题。