标签：rfs 阿里 ola 系统 字节 分布式文件 rocksdb postgre 事先
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种手段：
下面来看下常见的存储引擎或者数据库系统他们是怎么解决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的完整性。
标签：rfs 阿里 ola 系统 字节 分布式文件 rocksdb postgre 事先
原文地址：https://www.cnblogs.com/wsw-seu/p/12442691.html
