Related Documentation Download this Manual Excerpts from this Manual

MySQL 5.7 Reference Manual  /  Restrictions and Limits  /  Restrictions on XA Transactions

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.

For XA START, the JOIN and RESUME clauses are not supported.

For XA END, the SUSPEND [FOR MIGRATE] clause is not supported.

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 crash-safe with respect to the binary log (on the master). If there is a crash 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 a crash 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 state and the binary log in an inconsistent state.

  • XA does not work with relay-log-info-repository=TABLE.

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

Download this Manual
User Comments
Sign Up Login You must be logged in to post a comment.