---

前言

在上一章中我们聊到了事务有四大特性：原子性、一致性、隔离性、持久性。本篇文章就持久性重点聊一下，在高性能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 阶段
  redo log落盘，此时redo log是prepare标志
• commit 阶段
  binlog落盘，此时把redo log标志又prepare变更为commit,表示redo log完整提交。

在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配置，在fsync阶段系统崩溃的话也会导致日志不完整而回滚。
所以MySQL的事务持久性，应该是客户端收到事务成功的消息，数据一定会被持久化，失败一定没持久化，至于发生异常，要视情况而定，是网络异常还是系统崩溃。