Today I was doing some tests with XA transactions in MySQL 5.6. The output of the XA RECOVER command to list transactions was hard to read because of the representation of the data column: The good news is that 5.7 has transaction information in performance_schema: mysql> select trx_id, isolation_level, state, xid, xa_state, access_mode -> from performance_schema.events_transactions_current; +-----------------+-----------------+--------+--------+----------+-------------+ | trx_id | isolation_level | state | xid | xa_state | access_mode | +-----------------+-----------------+--------+--------+----------+-------------+ | NULL | REPEATABLE READ | ACTIVE | x-1 | PREPARED | READ WRITE | | 421476507015704 | REPEATABLE READ | ACTIVE | NULL | NULL | READ WRITE | | NULL | REPEATABLE READ | ACTIVE | foo-1 | ACTIVE | READ WRITE | | NULL | REPEATABLE READ | ACTIVE | NULL | NULL | READ ONLY | | NULL | ...

The recently released TokuDB brings many features. One of those features is support for XA Transactions. InnoDB already has support for XA Transactions. XA Transactions are transactions which span multiple databases and or applications. XA Transactions use 2-phase commit, which is also the same method which MySQL Cluster uses. Internal XA Transactions are used to keep the binary log and InnoDB in sync. Demo 1: XA Transaction on 1 node: mysql55-tokudb6> XA START 'demo01'; Query OK, 0 rows affected (0.00 sec) mysql55-tokudb6> INSERT INTO xatest(name) VALUES('demo01'); Query OK, 1 row affected (0.01 sec) mysql55-tokudb6> SELECT * FROM xatest; +----+--------+ | id | name | +----+--------+ | 3 | demo01 | +----+--------+ 1 row in set (0.00 sec) mysql55-tokudb6> XA END 'demo01'; Query OK, 0 rows affected (0.00 sec) mysql55-tokudb6> XA PREPARE 'demo01'; Query OK, 0 rows affected (0.00 sec) mysql55-tokudb6> XA COMMIT 'demo01...