1       MySQL 外部XA分析

1.1     作用分析

MySQL数据库外部XA可以用在分布式数据库代理层，实现对MySQL数据库的分布式事务支持，例如开源的代理工具：ameoba[4]，网易的DDB，淘宝的TDDL，B2B的Cobar等等。

通过MySQL数据库外部XA，这些工具可以提供跨库的分布式事务。当然，这些工具也就成了外部XA事务的协调者角色。在crash recover时控制悬挂事务是全局commit，或者rollback。

在crash recover之后，外部应用程序可能会遇到以下几种情况：

• 情况一：分布式事务对应的MySQL数据库实例，部分完成prepare，部分未完成prepare。此时直接回滚完成prepare的实例即可。n_prepared < Total Nodes (处于prepare状态的节点数量要小于参与分布式事务的所有节点总数)。

• 情况二：分布式事务对应的MySQL实例，全部完成prepare，未开始进行commit。此时即可提交此事务，也可回滚此事务(根据分布式事务原理，所有节点都完成prepare，应该提交)。n_prepared = Total Nodes。

• 情况三：分布式事务对应的MySQL实例，全部完成prepare，并且部分节点已经完成commit。此时应该提交该事务处于prepare状态的节点。n_prepared < Total Nodes。对比情况三与情况一，仅仅通过prepare节点的数量无法区分，因此应用程序需要在prepare完成之后记录日志(此时，应用程序起着事务协调者(Transcaction Coordinator)的角色，而根据MariaDB WorkLog#132[5]的说法，TC角色是可以进行”middle engine”优化的，不需要prepare过程，所有MySQL节点xa prepare返回之后，应用程序直接写commit标识即可，然后再对每个MySQL节点进行xa commit操作。)，从而用于区分情况一与情况三。

• 情况四：分布式事务对应的MySQL实例，全部完成commit。此时事务已经提交成功，xid不会出现在执行xa recover的任一个节点。不需要特殊处理。

• 情况五：未记录任何prepare日志。那么所有的事务，在各个存储引擎的crash recover时，都会被回滚，不需要外部特殊处理。

1.2     MySQL外部XA不足

通过前面的分析，可知应用程序配合MySQL的XA事务功能，能够较好的支持分布式环境下的事务。但是，这个支持并不完美，根据我的分析，有可能会出现以下几个问题：

l  问题一：主备数据库的数据不一致。

MySQL数据库的主备数据库的同步，通过Binlog的复制完成。而Binlog是MySQL数据库内部XA事务的协调者，并且MySQL数据库为binlog做了优化——binlog不写prepare日志，只写commit日志。

考虑前面提到的情况二，所有的参与节点prepare完成，在进行xa commit前crash。crash recover如果选择commit此事务。由于binlog在prepare阶段未写，因此主库中看来，此分布式事务最终提交了，但是此事务的操作并未写到binlog中，因此也就未能成功复制到备库，从而导致主备库数据不一致的情况出现。

在MySQL 5.5.16版本中做过测试，这个问题实际存在。crash recover之后，对xa recover返回的事务运行xa commit，对应事务提交，但是操作并未写入binlog，因此无法复制到备库。

那么是否回滚所有prepare的事务，就可以避免此问题呢？结论是仍旧不行，不仅不能解决问题一，甚至可能引起问题二。

l  问题二：同一事务，在各参与节点，最终状态不一致(部分提交，部分回滚)。

若回滚所有prepare状态的分布式事务，会产生问题二。考虑情况三(所有节点完成prepare，部分节点完成commit)，该分布式事务对应的节点，部分已经提交，无法回滚，而部分节点回滚。最终导致同一分布式事务，在各参与节点，最终状态不一致。

l  问题三：源码级别问题。MySQL 5.1.49源码对于外部XA事务处理存在bug，在MySQL 5.5.16版本中，此bug已经被fix。经过验证发现，在我已下载的MySQL 5.1.61与之后的所有版本，此bug均已经被fix。

在MySQL 5.1.49中，所有xa recover返回的外部xid，都不能被提交。原因如下：

当运行xa commit ‘xid_name’命令时，MySQL会判断当前xid_name的错误信息，若存在错误信息，那么就在内部将xa commit命令强制转换为xa rollback。xid_name的状态存于xid_cache中，在crash recover阶段，由函数Handler.cc::xarecover_handlerton调用xid_cache_insert(&xid_cache, x)函数完成插入。MySQL 5.1.49在实现xid_cache_insert函数有bug。

…

xs->xa_state=xa_state;

xs->xid.set(xid);

xs->in_thd=0;

xs->rm_error=0;

res=my_hash_insert(&xid_cache, (uchar*)xs);

…

MySQL 5.1.49中，缺少了xs->rm_error =0这一行，未初始化rm_error，导致xa commit时判断出错，无法commit。MySQL 5.5.16已经fix此bug，加上了黑色这一行的初始化，应用程序可以xa commit。

1.3     不足的解决方案

从MySQL数据库外部分布式事务XA不足的分析可以看出，除了实现bug之外，产生其余两个问题的最大原因，还是在于MySQL针对binlog做的 ”middle engine” 优化，binlog的prepare不写日志。在MySQL内部XA事务中，这个优化是可行的，因为Binlog本身的角色就是事务协调者(Transaction Coordinator)，事务协调者可以不进行prepare [5]。

但是对于MySQL外部XA事务，Binlog已经不是事务协调者的角色，其也是一个参与者，或者说是Resource Manager。因此Binlog的prepare日志是不可省略的。

为了解决MySQL数据库外部XA分布式事务crash recover过程中出现的问题，我觉得只能修改binlog模块。使binlog模块在正常运行过程中也区分内部XA事务与外部XA事务。内部XA事务可以仍旧沿用现在的方案；而外部XA分布式事务，需要增加写prepare日志的功能，已经crash recover时处理prepare日志的功能。

2       参考资料

[1] Sergei Golubchik. Distributed Transaction Processing with MySQL XA

[2] http://dev.mysql.com/doc/refman/5.1/en/xa.html

[3] X/Open. Distributed TP: The XA Specification

[4] 陈思儒. Amoeba

[5] MariaDB WorkLog#132: Transaction coordinator plugin

建议继续学习：

1. 分布式缓存系统 Memcached 入门    (阅读：14422)
2. Zookeeper工作原理    (阅读：10160)
3. GFS, HDFS, Blob File System架构对比    (阅读：9214)
4. Zookeeper研究和应用    (阅读：8347)
5. 分布式日志系统scribe使用手记    (阅读：7882)
6. 一致性哈希算法及其在分布式系统中的应用    (阅读：7753)
7. 分布式哈希和一致性哈希    (阅读：7442)
8. HBase技术介绍    (阅读：6574)
9. 分布式系统的事务处理    (阅读：5725)
10. Memcache分布式部署方案    (阅读：5289)