redo log的两阶段提交

Sat, May 8, 2021 阅读时间 1 分钟

WAL技术

WAL(Write-Ahead Logging),就是先些日志,再写磁盘。

当我们向MySQL更新一条记录的时候,InnoDB存储引擎就会把记录顺序的写到redo log中,然后更新InnoDB的buffer pool,并不更新磁盘中的数据页,然后这次更新操作就算是完成了,之后InnoDB存储引擎就会在它有空的时候,把redo log中记录的记录刷到磁盘上的数据页中完成最终的持久化。

由于磁盘的顺序写入效率要远高于随机写入,并且还有组提交等优化,这种方式可以大大提高数据更新时的效率。

关于磁盘的顺序写入,需要注意一下。不是说打开一个文件之后append就是顺序写入了。顺序写入需要知道磁盘上要写入的
位置,直接操作磁盘,向某个特定的地址写入,顺序写入时,磁盘的磁头不需要移动就可以直接写入,这样才有效率的提升。

Redo log

Redo log是Innodb存储引擎提供的用于优化更新操作的日志。它的结构可以看成是个环形的磁盘区域。

比如上图的redo log由四个文件组成,当向redo log中顺序写时,就是依次的写这四个文件,当写满时,就再从第一个文件开始写起。write_pos就是当前磁头的位置,一边写一边后移,checkpoint是当前擦除的位置点,他们之间就是可以写的区域。

Redo log大小是固定的,默认是4GB。Redo log不仅提高了数据更新时的效率,还让InnoDB拥有了crash-safe的能力,即不会因为宕机而丢数据,即如果数据在写入磁盘时宕机,可以通过redo log恢复过来。

Redo log和binlog的不同

  1. redo log是InnoDB特有的,是存储引擎层的,用于crash-safe;binlog是Server层的,所有引擎都可以使用,主要用于数据归档。
  2. redo log是物理逻辑日志,会记录数据页的位置,数据页内部则是逻辑日志,而binlog是单纯的逻辑日志,记录的就是每行的数据。
物理日志:记录的是具体的对磁盘的操作,比如在哪个位置,做了哪个修改
逻辑日志:可以理解为SQL语句,人类是可读的
物理逻辑日志:redo log,记录页位置是物理的,记录数据内容是逻辑的
  1. redo log有固定大小,写满了时需要进行擦除,擦除就要强制刷盘,binlog是没有大小限制的,在写到一定大小时,可以开启一个新文件接着写入。

两阶段提交

由于原本的MySQL只有MyISAM引擎,它不支持crash-safe,所以binlog也没有crash-safe的能力(因为它没有checkpoint,存储引擎不知道该从哪恢复)。而InnoDB存储引擎为了支持crash-safe,又不能改binlog,就提供了Redo log作为保证crash-safe的工具。而这两个日志同时存在,并且都会记录数据的更新操作,所以就得保证两个日志文件上的记录是一致的。两阶段提交解决的就是redo log和binlog的数据一致性的问题

两阶段提交的过程

  1. InnoDB接到了Server层执行器的更新数据的请求,会先将这行数据写入undolog(用于事务回滚的日志)
  2. 然后写入InnoDB的buffer pool中
  3. 然后将这个操作记录到redo log上,此时redo log处于prepare状态,然后InnoDB会告知MySQL的执行器,事务已经执行完了,随时可以提交
  4. MySQL执行器在收到通知后,就会将操作和数据写入binlog,并调用InnoDB的接口进行提交
  5. InnoDB将刚刚写入redo log的语句置为commit状态,本次事务就结束了

下图是一个例子:

两阶段提交的必要性

  • 假如只是先写redo log然后再写binlog

    假如redo log写完,binlog没写完时MySQL挂了,后续恢复时,就可以通过redo log恢复这次的数据,但是binlog中却没有记录,就会导致binlog中和实际数据库中存储的数据不一致。后续如果要使用这个binlog来恢复临时库的话,就会有数据不一致。

  • 假如只是先写binlog然后再写redo log

    假如binlog写完,redolog没写时Mysql挂了,就会导致重启后无法恢复(因为redo log没有),丢一次操作,但是binlog中却记录了这次操作,后续使用binlog恢复临时库时,就会比源库多一次操作出来,导致数据不一致。

我们再观察一下整个过程中的状态变化,以及任意一步出现问题时MySQL的处理

  1. 写入redo log,进入prepare状态
  2. 写入binlog
  3. 写入redo log,进入commit阶段

如果在1和2之间MySQL宕机,则会导致redo log处于prepare阶段,而binlog未写入,此时MySQL重启时,发现redo log处于prepare阶段,就会检查binlog,观察到binlog中没有这条事务的记录,则会忽视这条redo log。redo log和bin log之间通过事务ID对应

事务ID即transaction_id,在每个事务开始时分配,递增且全局唯一。

如果在2和3之间MySQL宕机,则redo log仍是处于prepare阶段,但是binlog已经写入了,此时MySQL重启时,发现redo log处于prepare阶段,就会检查binlog,观察到binlog是完整的,则会自动将这条redo log提交,并恢复数据。

MySQL的两阶段提交实际上是XA规范的应用,两阶段提交是分布式系统维持数据逻辑一致性时的常用方案。