MySQL 的 crash-safe浅谈

MySql执行流程
MySQL 的 crash-safe浅谈_第1张图片
MySQL 的 crash-safe浅谈_第2张图片

MySQL作为当下最流行的开源关系型数据库,有一个很关键和基本的能力,就是必须能够保证数据不会丢。那么在这个能力背后,MySQL是如何设计才能保证不管在什么时间崩溃,恢复后都能保证数据不会丢呢?有哪些关键技术支撑了这个能力;
MySQL 保证数据不会丢的能力主要体现在两方面:

  • 能够恢复到任何时间点的状态;
  • 能够保证MySQL在任何时间段突然奔溃,重启后之前提交的记录都不会丢失;
    对于第一点将MySQL恢复到任何时间点的状态,相信很多人都知道,只要保留有足够的binlog,就能通过重跑binlog来实现。
    对于第二点的能力,也就是本文标题所讲的crash-safe。即在 InnoDB 存储引擎中,事务提交过程中任何阶段,MySQL突然奔溃,重启后都能保证事务的完整性,已提交的数据不会丢失,未提交完整的数据会自动进行回滚。这个能力依赖的就是redo log和unod log两个日志。
    MySQL 的 crash-safe浅谈_第3张图片
    因为crash-safe主要体现在事务执行过程中突然奔溃,重启后能保证事务完整性,所以在讲解具体原理之前,先了解下MySQL事务执行有哪些关键阶段,后面才能依据这几个阶段来进行解析。下面以一条更新语句的执行流程为例,话不多说,直接上图:

从上图可以清晰地看出一条更新语句在MySQL中是怎么执行的,简单进行总结一下:

  1. 从内存中找出这条数据记录,对其进行更新;
  2. 将对数据页的更改记录到redo log中;
  3. 将逻辑操作记录到binlog中;
  4. 对于内存中的数据和日志,都是由后台线程,当触发到落盘规则后再异步进行刷盘;

上面演示了一条更新语句的详细执行过程,接下来咱们通过解答问题,带着问题来剖析这个crash-safe的设计原理。

  • 问题:为什么不直接更改磁盘中的数据,而要在内存中更改,然后还需要写日志,最后再落盘这么复杂?
    这个问题相信很多同学都能猜出来,MySQL更改数据的时候,之所以不直接写磁盘文件中的数据,最主要就是性能问题。因为直接写磁盘文件是随机写,开销大性能低,没办法满足MySQL的性能要求。所以才会设计成先在内存中对数据进行更改,再异步落盘。但是内存总是不可靠,万一断电重启,还没来得及落盘的内存数据就会丢失,所以还需要加上写日志这个步骤,万一断电重启,还能通过日志中的记录进行恢复。
    二、WAL技术
    写日志虽然也是写磁盘,但是它是顺序写,相比随机写开销更小,能提升语句执行的性能(针对顺序写为什么比随机写更快,可以比喻为你有一个本子,按照顺序一页一页写肯定比写一个字都要找到对应页写快得多)。
    这个技术就是大多数存储系统基本都会用的WAL(Write Ahead Log)技术,也称为日志先行的技术,指的是对数据文件进行修改前,必须将修改先记录日志。保证了数据一致性和持久性,并且提升语句执行性能。
    核心日志
    ● 问题:更新SQL语句执行流程中,总共需要写3个日志,这3个是不是都需要,能不能进行简化?
    更新SQL执行过程中,总共涉及MySQL日志模块其中的三个核心日志,分别是redo log(重做日志)、undo log(回滚日志)、binlog(归档日志)。这里提前预告,crash-safe的能力主要依赖的就是这三大日志。
    接下来,针对每个日志将单独介绍各自的作用,然后再来评估是否能简化掉。
    三、核心日志模块

四、两阶段提交
五、组提交
六、数据恢复流程
七、总结

你可能感兴趣的:(mysql,数据库)