MySQL数据库分布式事务XA的实现原理分析

　　1 原理　　关于MySQL数据库的分布式事务XA，分布式事务实现的原理，可见[3];关于MySQL XA的说明，可见[1][2]。　　MySQL XA分为两类，内部XA与外部XA;内部XA用于同一实例下跨多个引擎的事务，由大家熟悉的Binlog作为协调者;外部XA用于跨多MySQL实例的分布式事务，需要应用层介入作为协调者(崩溃时的悬挂事务，全局提交还是回滚，需要由应用层决定，对应用层的实现要求较高);　　本文，假设读者已经知道MySQL数据库外部分布式事务XA的使用，而将重点放在MySQL数据库，如何处理外部分布式事务XA的crash recover，以及面对不同的crash recover的情形，应用程序如何处理，才能够保证分布式事务的一致性。最后，本文简单分析一下目前MySQL数据库外部XA支持存在的问题，以及可选的解决方案。　　源代码分析基于MySQL 5.1.49，MySQL 5.5.16。
　　2 MySQL处理流程
　　2.1 MySQL 外部XA – 正常处理流程　　MySQL数据库外部XA的正常处理流程，开发云主机域名这里不准备介绍，可以参考[1][2][3]。接下来我重点描述一下MySQL数据库外部分布式事务XA的崩溃恢复流程，毕竟此流程跟应用程序如何正确使用外部XA息息相关。
　　2.2 MySQL外部XA – 崩溃恢复流程　　若一个运行外部XA分布式事务的MySQL数据库节点发生崩溃，那么其重启之后的崩溃恢复，涉及到外部XA处理的流程如下：　　Crash recover：　　通过以上的分析，可以总结出：　　MySQL数据库内部，会对xid做区分。内部xid有MySQL数据库自己产生(MySQL内部xid格式，将在本文下面给出)，用于多引擎间事务的一致性;外部xid由应用程序给出，用于跨多MySQL实例的分布式事务。但是存储引擎层不做区分(区分在MySQL上层)。　　crash recover时，存储引擎负责将引擎内部，处于prepare状态的事务收集，并返回MySQL上层。　　Binlog作为内部XA的协调者[5]，在binlog中出现的内部xid，在crash recover时，由binlog负责提交;在binlog中未出现的xid，由binlog负责回滚。(这是因为，binlog不进行prepare，只进行commit，因此在binlog中出现的内部xid，一定能够保证其在底层各存储引擎中已经完成prepare)。　　外部XA事务的xid，在crash recover过程中仅仅是插入xid_cache中，而不做其他处理。等到用户发起xa recover命令时，将xid_cache中处于prepare状态的xid返回。　　xa recover命令的流程处理如下。　　xa recover命令处理流程：　　根据xa recover命令收集到的各MySQL数据库实例返回的xid列表，然后再对比应用程序端日志，决定这些xid，哪些全局commit，哪些rollback。　　由于测试中只有一个MySQL数据库实例，因此此时可以直接选择commit处于prepare状态的xid。　　注：　　因此，使用时应该注意，不要在外部构造这种形式的xid，否则MySQL数据库就会将内部xid与外部xid混淆。　　一般情况下，构造一个内部xid比较困难，由于server_id一般小于4 bytes，不足的部分以ASCI NIL(null)补齐，而应用程序一般都不会构造此类的外部xid。
参考资料 [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
该文章出自
http://www.searchdatabase.com.cn/showcontent_58646.htm

相关推荐: binlog2sql参考

安装pip，参照安装网址：https://pip.pypa.io/en/stable/installing/curl https://bootstrap.pypa.io/get-pip.py -o get-pip.pypython get-pip.py安装gi…