MongoDB中WiredTiger的数据可用性设置
此文已由作者温正湖授权网易云社区发布。
欢迎访问网易云社区，了解更多网易技术产品运营经验。
MongoDB中WiredTiger的参数配置主要通过 wiredtiger_open （http://source.wiredtiger.com/2.9.1/group__wt.html#ga9e6adae3fc6964ef837a62795c7840ed）进行配置。
checkpoint检查点：
默认60s或2G redo触发checkpoint，也可以通过syncPeriodSecs调整，但官方强烈建议不调整；WT可通过checkpoint_sync（未在MongoDB中暴露）来调整checkpoint时的行为，默认会将数据持久化到存储介质中。
journal：
即redo日志，默认开启redo，每50ms刷新一次，时间无法设置。与MySQL的InnoDB redo不同，wt的redo类似MySQL Binlog文件，大约每写满100MB就会创建新的redo文件，此时会刷新旧的redo文件，最后一次检查点前的redo日志文件会被自动删除。
MongoDB wt的崩溃恢复大概流程为：查找wt元数据，先将数据恢复到最近一个已完成的checkpoint点，由于wt数据插入和更新采用COW(copy on write)机制，所以该恢复过程非常快；之后，在redo文件中查找是否有checkpoint点之后的日志，若有，则回放这些日志。
WT层持久性
从上可以看出，MongoDB中的wt并未设置为commit-level的数据持久性，而仅仅是checkpoint-level的持久性，但由于每50ms都会flush redo，所以虽有数据丢失，但由于每50ms一刷新，正常情况下丢失数据量很少，最多也不会超过100MB。由于生产环境中，MongoDB一般配置为replica set，丢失的那部分数据，也可以通过oplog复制从其他节点补上。
WT层IO方式
此项在MongoDB中没有显式配置，所以使用默认值。
WT可通过direct_io来调整打开文件时的行为，可配置data、log文件或checkpoint时走DirectIO，默认为空，也就是说这三种IO都走Buffer IO模式，即使用Linux内核的page cache；可通过mmap配置项来设置是否尽可能走MMAP内存访问模式，默认开启；
此外，还可为每次事务定义IO行为，通过transaction_sync进行配置，包括详细可参考（http://source.wiredtiger.com/2.9.1/tune_durability.html），默认在事务提交的时候不flush日志，仅在checkpoint的时候，或sync的时候刷。刷日志的行为可选择fsync或dsync（官方说区别不大）。
MongoDB层持久性
虽然MongoDB在wt设置层面没有做到commit-level的持久性。但对于MongoDB插入和更新操作，如果write concern中设置j:true，则确保了每次操作内容都会持久化到redo中。而且MongoDB 3.2复制集协议protocolVersion: 1（类raft）时，如果开启了journal，则write concern中的j为true，除非用户修改了驱动/复制集设置，或者在操作时显式指定j:false。
所以，从MongoDB整体上看，实现了操作级别（事务级别）的数据持久性。如果复制集配置write concern的w为majority，则能够确保插入和更新操作成功返回用户后，数据已经持久化到大多数节点。
此文已由作者温正湖授权网易云社区发布。
欢迎访问网易云社区，了解更多网易技术产品运营经验。
MongoDB中WiredTiger的参数配置主要通过 wiredtiger_open （http://source.wiredtiger.com/2.9.1/group__wt.html#ga9e6adae3fc6964ef837a62795c7840ed）进行配置。
checkpoint检查点：
默认60s或2G redo触发checkpoint，也可以通过syncPeriodSecs调整，但官方强烈建议不调整；WT可通过checkpoint_sync（未在MongoDB中暴露）来调整checkpoint时的行为，默认会将数据持久化到存储介质中。
journal：
即redo日志，默认开启redo，每50ms刷新一次，时间无法设置。与MySQL的InnoDB redo不同，wt的redo类似MySQL Binlog文件，大约每写满100MB就会创建新的redo文件，此时会刷新旧的redo文件，最后一次检查点前的redo日志文件会被自动删除。
MongoDB wt的崩溃恢复大概流程为：查找wt元数据，先将数据恢复到最近一个已完成的checkpoint点，由于wt数据插入和更新采用COW(copy on write)机制，所以该恢复过程非常快；之后，在redo文件中查找是否有checkpoint点之后的日志，若有，则回放这些日志。
WT层持久性
从上可以看出，MongoDB中的wt并未设置为commit-level的数据持久性，而仅仅是checkpoint-level的持久性，但由于每50ms都会flush redo，所以虽有数据丢失，但由于每50ms一刷新，正常情况下丢失数据量很少，最多也不会超过100MB。由于生产环境中，MongoDB一般配置为replica set，丢失的那部分数据，也可以通过oplog复制从其他节点补上。
WT层IO方式
此项在MongoDB中没有显式配置，所以使用默认值。
WT可通过direct_io来调整打开文件时的行为，可配置data、log文件或checkpoint时走DirectIO，默认为空，也就是说这三种IO都走Buffer IO模式，即使用Linux内核的page cache；可通过mmap配置项来设置是否尽可能走MMAP内存访问模式，默认开启；
此外，还可为每次事务定义IO行为，通过transaction_sync进行配置，包括详细可参考（http://source.wiredtiger.com/2.9.1/tune_durability.html），默认在事务提交的时候不flush日志，仅在checkpoint的时候，或sync的时候刷。刷日志的行为可选择fsync或dsync（官方说区别不大）。
MongoDB层持久性
虽然MongoDB在wt设置层面没有做到commit-level的持久性。但对于MongoDB插入和更新操作，如果write concern中设置j:true，则确保了每次操作内容都会持久化到redo中。而且MongoDB 3.2复制集协议protocolVersion: 1（类raft）时，如果开启了journal，则write concern中的j为true，除非用户修改了驱动/复制集设置，或者在操作时显式指定j:false。
所以，从MongoDB整体上看，实现了操作级别（事务级别）的数据持久性。如果复制集配置write concern的w为majority，则能够确保插入和更新操作成功返回用户后，数据已经持久化到大多数节点。