MySQL 5.6 Reference Manual Including MySQL NDB Cluster 7.3-7.4 Reference Guide
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
.
For XA
START
, the JOIN
and
RESUME
clauses are recognized but have no
effect.
For XA
END
the SUSPEND [FOR MIGRATE]
clause is recognized but has no effect.
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.
If an XA transaction has reached the PREPARED
state and the MySQL server is killed (for example, with
kill -9 on Unix) or shuts down abnormally,
the transaction can be continued after the server restarts.
However, if the client reconnects and commits the transaction,
the transaction is absent from the binary log even though it has
been committed. This means the data and the binary log have gone
out of synchrony. An implication is that XA cannot be used
safely together with replication.
It is possible that the server rolls back a pending XA
transaction, even one that has reached the
PREPARED
state. This happens if a client
connection terminates and the server continues to run, or if
clients are connected and the server shuts down gracefully. (In
the latter case, the server marks each connection to be
terminated, and then rolls back the PREPARED
XA transaction associated with it.) It should be possible to
commit or roll back a PREPARED
XA
transaction, but this cannot be done without changes to the
binary logging mechanism.
FLUSH TABLES WITH READ LOCK
is
not compatible with XA transactions.