MySQL的内部XA的二阶段提交-博客_易查网-资源共享平台-IDEA激活码-语言基础教程-视频教程

MySQL的内部XA的二阶段提交

2024-01-16 10:41:54 133

内部XA

可能大家一听感觉很陌生，什么是XA？XA是一种分布式事务管理规范，MySQL内部有一个XA事务管理器来支持分布式事务，可能这么一听更懵了，那么我这么解释一下，MySQL是支持主从的，主从分布在不同的机器，也就是说MySQL也是分布式的。不同的MySQL节点之前靠什么同步？靠binlog。但是单个MySQL服务靠什么支持事务的？靠redo-log和undo-log。其实XA就是为了解决redo-log和bin-log数据不同步的问题

日志的相关概念

我们简单说一下redo-log和bin-log的相关概念，undo-log上一篇文章介绍过

redo-log

又称重放日志，主要用于保持数据一致性和完整性，因为当我们修改一条记录的时候，不可能把整个page都刷到磁盘再返给客户端，我们知道，一个page默认是16kb，如果改了一个字符而和磁盘刷新16KB是不明智的，那么怎么办？MySQL将这个操作影响的数据存入一个日志中去，只需要一个简单的记录，比如test表的位移100改为a，，然后刷入磁盘（log buffer满了也会刷入磁盘）即可。

bin-log

binlog 是 binary log 的缩写，即二进制日志。 binlog 中记载了数据库发生的变化，比方说新建了一个数据库或者表、表结构发生改变、表中的数据发生了变化时都会记录相应的binlog日志。主要用于MySQL节点间的数据同步和恢复。

抛出问题

前面我们说了，内部XA是为了解决redo-log和bin-log数据不同步的问题，那么会出现哪种问题呢？那么我问一句，redo-log 和bin-log 应该哪个先crash？如果先crash redo-log 会发生什么问题？比如我们执行了一个insert操作，然后主节点a服务器crash redo-log之后服务宕机了，还没来得及写入bin-log，服务器恢复之后，由于其他机器没有insert的bin-log导致a服务器和其他服务器数据不一致如果先crash bin-log 我们执行了一个insert操作，主节点a服务器crash bin-log后服务宕机，服务恢复之后，其他节点根据bin-log执行了insert，但是服务a并没有redo-log，不会恢复数据，同样导致数据不一致。

二阶段提交

那么怎么才能保证redo-log和bin-log的一致呢？最简单的方式，等redo-log和bin-log都写入才算执行成功不就行了。说的很好，但是肯定不能两个同时写入，而是要先写一个再写另外一个，这里MySQL就用到了两阶段提交来解决这个问题我们来举一个例子，执行一个sql upate table1 set name ='张三' where id=1，那么这是一个怎么样的执行流程呢,大概流程如下:

在内存中查找id=1的记录，没有的话从磁盘中读取到内存中，并返回记录
记录undo-log
更新记录
开启第一阶段提交，进入prepare阶段，生成xid,写入redo-log，并标记为prepare
写入bin-log
提交事务，进入第二阶段提交，处于commit状态

注：下图是截取自其他博文的流程图

数据恢复

当服务宕机重启后，MySQL怎么实现数据恢复的呢，我们看下面的情况

redo-log 为空或者全部commit ,这个时候与binlog是一致的
redo-log 为prepare的情况下MySQL在恢复数据的时候会在redo-log中找到全局唯一的XID，然后拿着XID去bin-log里面查看有没有同步过去，如果同步过去了，就把redo-log的状态改为commit并提交，如果没有找到则说明bin-log没有写入成功，放弃提交