C.6 Restrictions on XA Transactions

XA transaction support is limited to the InnoDB
storage engine.

For “external XA,” a MySQL server acts as a Resource
Manager and client programs act as Transaction Managers. For
“Internal XA”, storage engines within a MySQL server
act as RMs, and the server itself acts as a TM. Internal XA
support is limited by the capabilities of individual storage
engines. Internal XA is required for handling XA transactions that
involve more than one storage engine. The implementation of
internal XA requires that a storage engine support two-phase
commit at the table handler level, and currently this is true only
for InnoDB.

The requirement that the bqual part of
the xid value be different for each XA
transaction within a global transaction is a limitation of the
current MySQL XA implementation. It is not part of the XA
specification.

Prior to MySQL 5.7.7, XA transactions were not compatible with
replication. This was because an XA transaction that was in
PREPARED state would be rolled back on clean
server shutdown or client disconnect. Similarly, an XA transaction
that was in PREPARED state would still exist in
PREPARED state in case the server was shutdown
abnormally and then started again, but the contents of the
transaction could not be written to the binary log. In both of
these situations the XA transaction could not be replicated
correctly.

In MySQL 5.7.7 and later, there is a change in behavior and an XA
transaction is written to the binary log in two parts. When
XA PREPARE is issued, the first part of the
transaction up to XA PREPARE is written using
an initial GTID. A XA_prepare_log_event is used
to identify such transactions in the binary log. When XA
COMMIT or XA ROLLBACK is issued, a
second part of the transaction containing only the XA
COMMIT or XA ROLLBACK statement is
written using a second GTID. Note that the initial part of the
transaction, identified by
XA_prepare_log_event, is not necessarily
followed by its XA COMMIT or XA
ROLLBACK, which can cause interleaved binary logging of
any two XA transactions. The two parts of the XA transaction can
even appear in different binary log files. This means that an XA
transaction in PREPARED state is now persistent
until an explicit XA COMMIT or XA
ROLLBACK statement is issued, ensuring that XA
transactions are compatible with replication.

The following restrictions exist for using XA transactions in
MySQL 5.7.7 and later:

XA is not fully resilient to an unexpected halt with respect
to the binary log (on the master). If there is an unexpected
halt before XA PREPARE, between XA
PREPARE and XA COMMIT (or
XA ROLLBACK), or after XA
COMMIT (or XA ROLLBACK), the
server and binary log are correctly recovered and taken to a
consistent state. However, if there is an unexpected halt in
the middle of the execution of one of these statements, the
server may not be able to recover to a correct state, leaving
the server and the binary log in an inconsistent state.

XA does not work with replication filters or binary log
filters. Filters are permitted as long as they do not render
any XA transactions empty. Filters that filter out XA
transactions may cause the slave to stop with an error.

In case GTIDs are enabled and the slave does not use either
log-bin=OFF or does not use
log-slave-updates, XA
transactions are not crash-safe with respect to GTIDs on the
slave. If the slave stops unexpectedly while applying an
XA PREPARE or XA COMMIT,
then after recovery @@GLOBAL.GTID_EXECUTED
may not correctly describe the transactions that have been
applied on the slave.