MySQL数据落盘原理(redo、undo、binlog、2PC、double write等。)

文章目录

• 前言
• 一、架构图
• • • 1、MySQL架构图
    • 2、InnoDB架构图
• 二、落盘分析
• • • 1.第一阶段
    • 2.第二阶段
    • 3.第三阶段
    • 4.第四阶段
    • 5.第五阶段
    • 6.第六阶段
• 三、落盘总结
• 四、崩溃恢复

前言

在上一章中我们聊到了事务有四大特性：原子性、一致性、隔离性、持久性。本篇文章就持久性重点聊一下，在高性能Mysql一书中，对持久性的定义是：一旦事务提交，则起所做的修改就会永久保存到数据库中，此时即使数据库或系统崩溃，修改的数据也不会丢失。
持久性这个概念有点模糊，因为实际上持久性也是分很多种不同的级别的，有些持久性策略能够提供很强的安全保障，有些则未必，并且不可能有能做到100%安全保障的持久性策略，下面我们逐步展开mysql种事务持久性的真正含义。

ps:基于innodb存储引擎

一、架构图

首先通过几张图片宏观上了解Mysql和innodb的架构

1、MySQL架构图

2、InnoDB架构图

通过以下两张innodb的架构图可以一目了然的看到innodb数据落盘过程

二、落盘分析

本节是将MySQL落盘过程由浅到深，由简单到复杂逐步分析，来达到理解落盘过程的目的。

1.第一阶段

假设此时MySQL修改数据后直接写入磁盘，就会有一个问题，数据写入磁盘时随机写的，性能极差，于是有了第二阶段。

2.第二阶段

此阶段增加了缓存这一步，即MySQL修改数据后保存在缓存中，然后由后台线程异步写入磁盘，这个过程也有一个明显的问题，当数据还在缓存中尚未写入磁盘时系统崩溃，会导致数据丢失，安全级别相当差，于是有了第三阶段。

3.第三阶段

此阶段增加了redo log,即更新缓存后，并且同步将redo log写入磁盘，由于redo log是顺序写词盘，所以效率也并不低。这时遇到数据还在缓存中尚未写入磁盘时系统崩溃的情况，MySQL重启是可以根据redo log的内容进行落盘。
但是此时会有脏读，不可重复读等问题，破坏了事务的隔离性。比如A事务更新了缓存但事务尚未提交，B事务去读就会读取到A事务的更新。
这个时候可能有人问了，那A事务更新的时候锁定数据不让B事务读可以吗？可以是可以，但是会导致读性能太差。于是有了第四阶段。

4.第四阶段

此阶段增加了undo log,即在更新缓存前先把对应的反向逻辑日志写到undo log buffer,这样B事务读取事务读取历史版本即可(mvcC机制）。
但是仔细一想还是有问题，那就是MySQL数据落盘是以页为单位的，其大小是16KB,而操作系统的页大小是4KB,如果在落盘的时候操作系统写了12KB时崩溃了，咋办？还有4KB数据呢（这种情况被称为部分写失效），这种情况下MySQL重启如何恢复？？
可能有些同学会想通过redo log来恢复，这是不行的，因为redo log记录的是对页的物理操作，如偏移量800，写’aaa’记录,所以redo log生效的前提必须是MySQL数据页是完整的（姜承尧.MySQL技术内幕:InnoDB存储引擎）。
此时在MySQL崩溃重启恢复应用redo log前，需要一个页的副本，当发生部分写失效时，先通过该页的副本来还原该页后再应用redo log,这里所谓的页副本，这种策略就是double write。于是有了第五阶段。

PS:关于undo log落盘
用户定义的临时表的 undo log不刷盘，非临时表的undo log要刷盘的，undo log记录了事务修改前逻辑日志，本质上是数据，和正常表区别不大，它的内容除了记录到undo tablespaces,也会被记录到redo log。其中刷盘到undo tablespaces的机制和正常表数据一致（异步刷盘），刷盘到redo log的机制是和该undo log其对应的redo log一起刷盘的。

5.第五阶段

此阶段增加了double write buffer,先将缓存中的数据搬到该缓冲区，再刷到共享表空间和各个独立表空间，细节如下：

double write由两部分组成，一部分是内存中的double write buffer，大小为2MB，另一部分是物理磁盘上共享表空间中连续的128个页，即2个区（extent），大小同样为2MB。在对缓冲池的脏页进行刷新时，并不直接写磁盘，而是会通过memcpy函数将脏页先复制到内存中的double write buffer，之后通过double write buffer再分两次，每次1MB顺序地写入共享表空间的物理磁盘上，然后马上调用fsync函数，同步磁盘，避免缓冲写带来的问题。在这个过程中，因为double write页是连续的，因此这个过程是顺序写的，开销并不是很大。在完成double write页的写入后，再将double write buffer中的页写入各个表空间文件中，此时的写入则是随机的，开销大。

这样就完美解决了 部分写失效 问题，即使写共享表空间失败，因为还没有写独立表空间，此时直接通过redo log恢复即可，如果写共享表空间成功，写独立表空间部分失败，先通过共享表空间的副本页恢复，再通过redo log恢复。

6.第六阶段

我们知道，在实际项目中，MySQL很少单节点，一般至少主从，双主等，此时必须开启binlog用于主从同步,那么binlog与redo log落盘关系如何呢？
如图所示，此时引入了XA分布式协议，保证binlog和redo log提交顺序。

• prepare 阶段
  write redo log到os cache，此时redo log是prepare标志
• commit 阶段
  binlog落盘，此时把redo log标志由prepare变更为commit（表示redo log完整提交）,再把redo log fsync到磁盘。

在MySQL崩溃恢复时，为了保证主从数据一致，检测到binlog完整（redo log至少prepare了），此时提交数据，如果binlog不完整或没有，则回滚数据，回滚用的redo log中的undo log的redo log（太绕了，好好梳理下）。

三、落盘总结

综上所述可知，MySQL的持久化策略也不是100%安全保障的。
由于系统崩溃后的数据提交与回滚基于binlog和redo log,我们先了解下其各自落盘的参数如下：
binlog的重要参数就是sync_binlog：

• sync_binlog=0：表示每次提交事务只把log写到os cache,并不执行fsync刷盘，刷盘取决于操作系统；
• sync_binlog=1：表示每次提交事务会将binlog刷盘（默认）;
• sync_binlog=N（N>=2): 表示每次提交事务只把log写到os cache，等累积到N个才执行fsync刷盘;

redo log的重要参数是innodb_flush_log_at_trx_commit:

• 0 – 每N秒将Redo Log Buffer的记录写入Redo Log文件，并且将文件刷入硬件存储1次。N由innodb_flush_log_at_timeout控制；
• 1 – 每个事务提交时，将记录从Redo Log Buffer写入Redo Log文件，并且将文件刷入硬件存储；
• 2 – 每个事务提交时，仅将记录从Redo Log Buffer写入Redo Log文件。Redo Log何时刷入硬件存储由操作系统和innodb_flush_log_at_timeout决定。这个选项可以保证在MySQL宕机，而操作系统正常工作时，数据的完整性。

根据参数含义可知，最安全的就是双1配置，在双1配置下可以得到如下分析：

假设字段name =“tom”,现在执行update语句令name =“Bob”,根据前面章节分析且在得到以下流程：

根据上图可以清晰的了解到data page,undo log,redo log,binlog四者的落盘先后顺序。

四、崩溃恢复

在讲崩溃恢复之前首先要说一下mysql 崩溃恢复时先rollforward（利用redo log恢复data和undo log）,再rollback(利用undo log回滚到历史版本)。

• 崩溃时刻A: 事务提交之前，此时事务没提交，肯定回滚，纵使后台page cleaner线程已经将data和undo log刷盘。
• 崩溃时刻B: xa_prepare阶段，此时redo log处于xa prepare阶段，binlog未刷盘，肯定回滚，纵使因redo log被写入os cache而落了盘，另外binlog未刷盘，不会传播到从库。
• 崩溃时刻C: xa_commmit阶段，此时binlog执行了刷盘，redo log尚未commit。需要根据xid关联binlog与redo log,若binlog不完整，则回滚事务，完整则提交事务。
• 崩溃时刻D: xa_commmit阶段，binlog已刷盘，redo log也commit，事务完整提交。

综上可知：
因为binlog已刷盘且完整，会传播到从库，所以mysql为了保证主从一致性，只要binlog完整就提交事务，否则回滚事务。

ps:

• 1： MySQL如何确定binlog完整性？
  一个事务的binlog有完整格式：
  statement格式，最后会有commit；
  row格式，最后会有个xid_log_event；
  MySQL 5.6.2版本后，引入binlog-checksum机制，验证binlog内容正确性。对于binlog日志由于系统崩溃等原因，可能会在写入日志中途出错，MySQL通过进行checksum校验binlog完整性。
• 2：redo log、binlog如何关联？
  二者有个共同数据字段XID。崩溃恢复时，会从最后一次checkpoint的位置开始顺序扫描redo log，若碰到既有prepare、又有commit的redo log，直接提交事务。若碰到只有prepare、无commit的redo log，就拿XID去binlog找对应事务，此时若binlog完整则提交事务，否则回滚事务。

来源地址：https://blog.csdn.net/weixin_38597669/article/details/130305313