Mysql支持两种XA：

外部XA

应用程序是协调者（coordinator），参数事务的服务器节点就是资源管理器（resource manager），目前存在两个问题：

问题1：当参数分布式事务的协调者退出后，即使参与分布式事务的节点都已经PREPARE成功。从理论上说，这时这些分布式事务是悬挂事务，协调者恢复后可以进行最后的第二阶段提交。但是这在MySQL数据库中是不可行的，协调者退出，整个XA事务都回滚；

--此问题不会导致数据丢失或不一致；

问题2：参与分布式事务的节点已经PREPARE成功，但是发生数据库宕机导致重启。这时重启之后可以发现悬挂的XA事务，可以进行提交。但是提交后，不写入二进制日志文件，这时会导致主从数据不一致。

那就写二进制日志嘛，问题不就解决了？是的，貌似可以。但是这对replication有很大的影响。因为分布式事务的PREPARE是在事务提交前就写了，但是二进制日志实在事务提交时才写的。这样会导致replication由于分布式事务，而导致可能被长时间等待的情况。

网易的MySQL分支版本InnoSQL中，已经对该问题进行了修复。修复的方案很简单，PREPARE成功的事务写日志，但并不是写在二进制日志中，而是写在每个对应分布式事务的单独文件中。

内部XA

现在mysql内部一个处理流程大概是这样：

1. prepare ，然后将redo log持久化到磁盘

2. 如果前面prepare成功，那么再继续将事务日志持久化到binlog

3. 如果前面成功，那么在redo log里面写上一个commit记录

那么假如在进行着三步时又任何一步失败，crash recovery是怎么进行的呢?

此时会先从redo log将最近一个检查点开始的事务读出来，然后参考binlog里面的事务进行恢复。

如果是在1 crash，那么自然整个事务都回滚；

如果是在2 crash，那么也会整个事务回滚；

如果是在3 crash（仅仅是commit记录没写成功），那么没有关系因为2中已经记录了此次事务的binlog，所以将这个进行commit。所以总结起来就是redo log里凡是prepare成功，但commit失败的事务都会先去binlog查找判断其是否存在（通过XID进行判断，是不是经常在binlog里面看到Xid=xxxx？这就是xa事务id），如果有则将这个事务commit，否则rollback。

http://www.csdn123.com/html/blogs/20130620/24553.htm

Mysql为TM，存储引擎为RM；

Internal XA要求存储引擎在table handler级别支持2阶段提交，5.6只支持innodb；

binlog本身也会prepare/commit，但是binlog的prepare阶段不做任何事情（意味着不可能失败），代码中可以看见binlog_prepare函数是空的，写入binlog的过程是在commit阶段做的（在其他事务存储引擎commit之前），binlog具有“原子”性：每个事务产生的binlog是连续、完整的写入到binlog文件中，事务之间不会交叉写（与InnoDB的redo log不同），因此在crash recovery阶段，如果redo log中未提交的事务能够在binlog中发现，说明其已经prepare成功，可以直接提交，而如果redo中未提交事务不在binlog中，直接回滚事务，这样能够保证binlog和存储引擎数据的一致。

innodb_support_xa

默认为true，如果关闭则binlog记录事务的顺序可能与实际不符，造成slave不一致

If you turn it off, transactions can be written to the binary log in a different order from the one in which the live database is committing them. This can produce different data when the binary log is replayed in disaster recovery or on a replication slave. Do not turn it off on a replication master server unless you have an unusual setup where only one thread is able to change data.

http://dev.mysql.com/doc/refman/5.6/en/xa-restrictions.html

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 will be 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

http://www.gpfeng.com/?p=298

http://insidemysql.blog.163.com/blog/static/2028340422013102662420500/