前序
InnoDB引擎有几个重点特性，为其带来了更好的性能和可靠性：mysql
-
插入缓冲（Insert Buffer）git
-
两次写（Double Write）web
-
自适应哈希索引（Adaptive Hash Index）sql
-
异步IO（Async IO）数据库
-
刷新邻接页（Flush Neighbor Page）微信
今天咱们的主题就是 两次写（Double Write）, 先一句话归纳下：架构
上一次咱们讲过Insert Buffer 是用来提升存储引擎性能上的提高，Double Write 就是为了在数据库崩溃恢复时保证数据不丢失的一个重要特性，保证了数据的可靠性。koa
概念点
如图，仍是先来讲几个基础的概念：异步
-
数据库表空间由段（segment）、区(extent)、页(page)组成编辑器
-
默认状况下有一个共享表空间ibdata1,如使用了innodb_file_per_table则每张表独立表空间（指存放数据、索引、插入缓冲bitmap页）
-
段包括了数据段（B+树的叶子结点）、索引段、回滚段
-
区，由连续的页组成，任何状况下每一个区都为1M，一个区中有64个连续页（16k）
-
页，数据页（B-tree Node）默认大小为16KB
-
文件系统一页 默认大小为4KB
-
盘片被分为许多扇形的区域，每一个区域叫一个扇区，硬盘中每一个扇区的大小固定为512字节
-
脏页，当数据从磁盘加载到缓冲池的数据页后，数据页内容被修改后，此数据页称为脏页
出现的问题
经过上次讲的 重要，知识点：InnoDB的插入缓冲 咱们知道，脏页会在某些场景下进行刷盘，将缓冲池内的脏页数据落地到磁盘。
由于存储引擎缓冲池内的数据页大小默认为16KB，而文件系统一页大小为4KB，因此在进行刷盘操做时，就有可能发生以下场景：
如图所示，数据库准备刷新脏页时，须要四次IO才能将16KB的数据页刷入磁盘。
但当执行完第二次IO时，数据库发生意外宕机，致使此时才刷了2个文件系统里的页，这种状况被称为写失效（partial page write）。
此时重启后，磁盘上就是不完整的数据页，就算使用redo log也是没法进行恢复的。
注意：
-
redo log没法恢复数据页损坏的问题，恢复必须是数据页正常而且redo log正常。
-
这里要知道一点，redo log中记录的是对页的物理操做，如偏移量600，写'xxxx'记录。
-
若是这个页自己已经发生了损坏，再对其进行重作是没有意义的
该怎么解决这个问题
那应该怎么来解决这个问题呢？其实你们想一下就会有个大概的答案，就是给它搞个备份呗。
若是写脏页的时候发生宕机，在重启后使用下备份先恢复下数据页在写磁盘就能够了，其实这就是Double Write 。
Double Write 出现
千呼万唤始出来，为了防止咱们可怜的数据被破坏，InnoDB存储引擎提供了重要的Double Write 特性，避免了数据丢失的惨剧发生。
下面咱们来慢慢的来看看Double Write 究竟是怎么提升可靠性的
Double Write 解决的问题
在数据库进行脏页刷新时，若是此时宕机，有可能会致使磁盘数据页损坏，丢失咱们重要的数据。此时就算重作日志也是没法进行恢复的，由于重作日志记录的是对页的物理修改。
其实就是在重作日志前，用户须要一个页的副本，当写入失效发生时，先经过页的副原本还原该页，再进行重作，这就是double write。
Double Write 架构
如图，其实Double Write 分为了两个组成部分：
-
内存中的double write buffer -
物理磁盘上共享表空间中连续的128个页，即2个区（extent），大小一样为2MB
能够看出，有了Double write后的脏页刷新流程就是多了几步操做：
-
在对缓冲池的脏页进行刷新时，并不直接写磁盘，而是会经过memcpy函数将脏页先复制到内存中的Double write buffer
-
经过Double write buffer再分两次，每次1MB顺序地写入共享表空间的物理磁盘上，而后立刻调用fsync函数，同步磁盘，避免缓冲写带来的问题
Double write崩溃恢复
如图，若是操做系统在将页写入磁盘的过程当中发生了崩溃，在恢复过程当中，InnoDB存储引擎能够从共享表空间中的Double write中找到该页的一个副本，将其复制到表空间文件，再应用重作日志。
下面显示了一个由Double write进行恢复的状况：
090923 12:36:32 mysqld restarted
090923 12:26:33 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Crash recovery may have faild for some .ibd files!
InnoDB: Restoring possible half-written data pages from the doublewrite.
InnoDB: buffer...
Double Write 的问题
Double write buffer 它是在物理文件上的一个buffer, 其实也就是file，因此它会致使系统有更多的fsync操做，而由于硬盘的fsync性能问题，因此也会影响到数据库的总体性能。
Double write页是连续的，所以这个过程是顺序写的，开销并非很大。
在完成Double write页的写入后，再将Double write buffer中的页写入各个数据文件中，此时的写入则是离散的
总结
-
当commit 一个修改语句时，若是redo log有空闲区域，直接写redo log，若是redo log没有空闲区域，那么须要把被覆盖的redo log对应的数据页刷新到data file 中，最后改pool buffer中的记录
-
innodb的redo log 不会记录完整的一页数据，由于这样日志太大，它只会记录那次（sequence）如何操做了（update,insert）哪页(page)的哪行(row)
-
由于数据库使用的页（page，默认16KB）大小和操做系统对磁盘的操做页（page，默认4KB）不同，当提交了一个页须要刷新到磁盘，会有屡次IO， 此时刷了前面的8k时异常发生宕机。在系统恢复正常后，若是没有double write机制，此时数据库磁盘内的数据页已损坏，没法使用redo log进行恢复。
-
若是有double write buffer，会检查double writer的数据的完整性，若是不完整直接丢弃double write buffer内容，从新执行那条redo log，若是double write buffer的数据是完整的，用double writer buffer的数据更新该数据页，跳过该redo log。
往期推荐
本文分享自微信公众号 - 架构技术专栏（jiagoujishu）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。