MySQL的内部XA的二阶段提交

2024-01-16 10:41:54 119

内部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,那么这是一个怎么样的执行流程呢,大概流程如下:

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

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

数据恢复

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

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