开发者社区> 余二五> 正文

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

简介:
+关注继续查看

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。

  MySQL处理流程

  1.MySQL 外部XA – 正常处理流程

  MySQL数据库外部XA的正常处理流程,这里不准备介绍,可以参考[1][2][3]。接下来我重点描述一下MySQL数据库外部分布式事务XA的崩溃恢复流程,毕竟此流程跟应用程序如何正确使用外部XA息息相关。

  2.MySQL外部XA – 崩溃恢复流程

  若一个运行外部XA分布式事务的MySQL数据库节点发生崩溃,那么其重启之后的崩溃恢复,涉及到外部XA处理的流程如下:

  Crash recover:

  // 1. 读取binlog文件,将文件中的xid存入commit_list hash表

  // 顾名思义,所谓的commit_list,就是说此list中对应prepare状态的xid

  // 在崩溃恢复过程中均可以被提交,而不在commit_list中的xid,均须回滚

  // binlog中的xid,都是属于内部xid,由MySQL产生,用于内部XA

  Log.cc::TC_LOG_BINLOG::recover
// 2. 遍历底层所有的事务引擎,收集处于XA_PREPARED状态的所有xid

  // 这些xid列表,既包括内部xid,也包括外部xid,存储引擎内部不做区分

  Handler.cc::ha_recover(commit_list)
// 执行各引擎层面提供的recover方法,收集所有的处于prepared状态的xid

  // 根据xid分类:

  // 3. 若xid属于内部xid,那么在commit_list中查找此xid,

  // 若存在,则提交此xid对应的事务;否则,回滚此事务

  // 4. 若xid属于外部xid,那么则将xid插入xid_cache hash表

  // xid_cache中的所有xid,将会通过xa recover命令返回,等待外部程序决策

  Handler.cc::xarecover_handlerton
// 5. 收集InnoDB存储引擎中,处于prepare状态的所有xid,并返回

  got = hton->recover (innobase_xa_recover)

  my_xid x = info->list[i].get_my_xid();

  if (!x)

  // 若当前为外部xid,那么将xid插入xid_cache hash表

  xid_cache_insert(&xid_cache, x);

  else

  if (x in commit_list)

  // 若当前为内部xid,同时此xid在binlog中存在,则提交

  hton->commit_by_xid();

  else

  // 若当前为内部xid,同时此xid在binlog中不存在,则回滚

  hton->rollback_by_xid();
通过以上的分析,可以总结出:

  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命令处理流程:

  sql_parse.cc::mysql_execute_command

  case SQLCOM_XA_RECOVER:

  mysql_xa_recover();

  // 遍历xid_cache,找出其中的状态处于XA_PREPARED的事务,发送客户端

  while (xs = hash_element(&xid_cache,))

  if (xs->xa_state == XA_PREPARED)

  protocol->write();
根据xa recover命令收集到的各MySQL数据库实例返回的xid列表,然后再对比应用程序端日志,决定这些xid,哪些全局commit,哪些rollback。

  由于测试中只有一个MySQL数据库实例,因此此时可以直接选择commit处于prepare状态的xid。

  注:

  MySQL内部xid格式: MYSQL_XID_PREFIX + server_id + my_xid

  MYSQL_XID_PREFIX: MySQLXid (源码写死) 8 bytes

  server_id: MySQL实例的id,ulong, 4 bytes

  my_xid: 内部自增序列,ulonglong, 8 bytes

  例如:”MySQLXid 0004”

  server_id = ‘ ’;my_xid = 4

  因此,使用时应该注意,不要在外部构造这种形式的xid,否则MySQL数据库就会将内部xid与外部xid混淆。

  一般情况下,构造一个内部xid比较困难,由于server_id一般小于4 bytes,不足的部分以ASCI NIL(null)补齐,而应用程序一般都不会构造此类的外部xid。
 








本文转自 wws5201985 51CTO博客,原文链接:http://blog.51cto.com/wws5201985/789451,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
DTCC 回顾:技术破局,分布式数据库创赢未来
2020 年 12 月 21 日第十一届中国数据库技术大会(DTCC 2020)于北京召开,蚂蚁集团 OceanBase 资深总监、北京奥星贝斯科技研发中心总经理杨传辉,带来了《OceanBase 原生分布式数据库》的主题分享,以下为演讲实录:
967 0
Kotlin里的Extension Functions实现原理分析
## Kotlin里的Extension Functions Kotlin里有所谓的扩展函数(Extension Functions),支持给现有的java类增加函数。 * https://kotlinlang.org/docs/reference/extensions.html 比如给`String`增加一个`hello`函数,可以这样子写: ```java
1242 0
MySQL:互联网公司常用分库分表方案汇总
不管是IO瓶颈,还是CPU瓶颈,最终都会导致数据库的活跃连接数增加,进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是,可用数据库连接少甚至无连接可用。接下来就可以想象了吧(并发量、吞吐量、崩溃)。
1653 0
微软轻量级系统监控工具sysmon原理与实现完全分析(上篇)
作者:浪子_三少 Sysmon是微软的一款轻量级的系统监控工具,最开始是由Sysinternals开发的,后来Sysinternals被微软收购,现在属于Sysinternals系列工具。它通过系统服务和驱动程序实现记录进程创建、文件访问以及网络信息的记录,并把相关的信息写入并展示在windows的日志事件里。经常有安全人员使用这款工具去记录并分析系统进程的活动来识别恶意或者异常活动。而本文讨论
1671 0
“分布式事务”的理解(适用于访问多个数据库之间)
        原文地址:http://blog.163.com/soli1988_blog/blog/static/176895272201212812416747/              总体来看,如果所有数据的修改仅依靠单个数据源就能完成,则这个事务就相当简单了。然而,随着商业需求的日益增加,应用程序变得越来越复杂,经常需要访问多个数据库,这些数据库通常分布在不同的地方,这就是
889 0
阿里云开源PolarDB数据库,与社区共建云原生分布式数据库生态
5月29日,阿里云开发者大会上,阿里巴巴宣布开源云原生数据库能力,对外开放关系型数据库PolarDB for PostgreSQL 源代码,服务百万开发者,与社区开发者一起共建云原生分布式数据库生态。“我们希望将阿里云在云原生分布式数据库技术上积累的丰富经验,通过标准技术组件和系统的方式开放出来,共建开源数据库生态。”阿里云智能数据库产品事业部负责人李飞飞表示。
19030 0
+关注
20377
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
JS零基础入门教程(上册)
立即下载
性能优化方法论
立即下载
手把手学习日志服务SLS,云启实验室实战指南
立即下载