innodb为什么需要doublewrite(转)

　　InnoDB的page size默认是16KB，而操作系统的一个block size是4KB，磁盘io block则更小。那么InnoDB的page刷到磁盘上要写4个操作系统block，在极端情况下（比如断电）不一定能保证4个块的写入原子性，假如只有一部分写是成功的，那么innodb的数据page就不是一个完整的page(break page)，这种现象称为partial write。

　

　innodb怎么解决partial write？

innodb采用的是doublewrite机制，在写数据page时，会写两遍到磁盘上，第一遍是写到doublewrite buffer（实际上是共享表空间的一块区域），第二遍是从doublewrite buffer写到真正的数据文件中。如果发生了partial write，InnoDB再次启动后就可以从doublewrite buffer中进行page的恢复。由于第一遍page落盘与第二遍page落盘在不同的时间点，所以不会出现doublewrite page和数据page同时发生partial write的情况。

　　innodb为什么不用redo log来恢复break page?

redo log的页大小一般设计为512个字节，因此redo log page本身不会发生break page。用redo log来解决partial write 理论上是可行的，不过innodb的redo log是逻辑物理日志（不做展开），并不是物理日志，因此发生partial write后崩溃恢复过程中不能直接应用redo log ，innodb发现break page后实际上会报错。

innodb能否通过其他方式解决partial write?

　　可以，如果系统表空间文件（“ibdata文件”）位于支持原子写入的Fusion-io设备上，就能避免partial write ，可以不用doublewrite机制。还有大名鼎鼎的阿里云polardb，在底层分布式文件系统PolarFS能提供页大小(如16)KB小的原子写入，无需double write 机制来避免partial write。还有XDB的DBFS也类似实现了原子写。

可以总结数据库为了解决partial write问题，一般有4种手段：

1. 事后恢复：innodb doublewirite 机制，事先存一份page的副本，当partial write发生需要恢复时，先通过page的副本来还原该page，再进行重做；
2. 事后恢复：物理redo log 恢复机制，物理redo log里面存有完整的数据page，当partial write发生需要恢复时，先通过redo log page的副本来还原该page，再进行重做可以保证幂等性；
3. 事先避免：底层存储来实现原子写入避免partial write；
4. 事先避免：数据库的page size 设置为块设备扇区大小512字节保证原子写避免partial write，如：innodb redo log 。

下面来看下常见的存储引擎或者数据库系统他们是怎么解决partial write的。

PostgreSQL

　　PG采用的是第二种方式。通过full_page_write机制，在物理redo log中写dirty page的full page解决了数据页的partial write问题。然而pg的redo log page size默认是8K的，不是512字节对齐物理磁盘block，所以理论上PG的redo log 也会存在partial write。不过redo log 的partial write并不会带来数据一致性的问题，因为假如出现了partial write说明事务未提交成功，那么崩溃恢复的时候对PG来说也是不会去恢复的。

MongoDB WiredTiger

　　WiredTiger中刷脏页是通过将内存中的btree修改过的PAGE做一次checkpoint并写入持久化存储，每个btree对应磁盘上一个物理文件，btree的每个PAGE以文件里的extent形式上的page。很显然checkpoint是一个append only方式，也就是说WiredTiger会保存多个checkpoint版本。由于原page并没有被更新，所以即使发生partial write，不管从哪个版本的checkpoint开始都可以通过重演journal log恢复来保证page的完整性。值得一提的是MongoDB 3.5.12中WiredTiger在内存和journal log中实现了in-place update，但数据写磁盘的机制并未改变，因此依然可以解决partial write。

RocksDB & InfluxDB

　　存储引擎采用LSM或者TSM（类LSM）的结构，数据page采用append only方式写入，而不是像innodb或PG一样采用in-place update的方式写入page，所以即使出现了partial write，由于原page没有变更，可以通过原page重做wal log恢复来保证page的完整性。