innodb为什么需要doublewrite(转)

时间:2022-01-04 17:04:54

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的完整性。