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和存储引擎数据的一致。
