【Mongo】存储引擎-WiredTiger概览

蔚落 2022-06-12 02:07 191阅读 0赞

### **一、WiredTiger整体架构** ###

**    **WiredTiger的写操作会先写入Cache，并持久化到WAL(Write ahead log)，每60s或log文件达到2GB时会做一次Checkpoint，将当前的数据持久化，产生一个新的快照。

![arch.jpg][]

*  `session 模块`，负责和wt引擎上层交互的句柄，每个session会关联多个cursor，cursor属于一个session
 *  `cache 模块`，主要有内存中的btree page(数据页，索引页，溢出页)构成
 *  `evict 模块`，如果cache内存紧张，触发cache淘汰，便利btree，并根据LRU排序淘汰
 *  `Journal 模块`，WAL log，类似InnoDB的redolog，保证数据持久化，通过定时和定量阈值来flush
 *  `checkpoint 模块`，类似InnoDB checkpoint机制，异步执行btree刷盘，checkpoint之后通知log模块更新log\_ckpt\_lsn(lsn概念和InnoDB一致)
 *  `block manager模块`，负责磁盘IO的读写，cache、evict、checkpoint模块均通过该模块访问磁盘

### **二、Cache Btree** ###

Wiredtiger的Cache采用Btree的方式组织，每个Btree节点为一个page，root page是btree的根节点，internal page是btree的中间索引节点，leaf page是真正存储数据的叶子节点；

btree的数据以page为单位按需从磁盘加载或写入磁盘

![image][]

持久化时，修改操作不会在原来的leaf page上进行，而是写入新分配的page，每次checkpoint都会产生一个新的root page。这样的好处是对不修改原有page，就能更好的并发。

![wt-snapshot.png][]

### **三、Checkpoint** ###

*  **    **每个客户端的写请求会先通过Journal进行持久化，提供参数 \{j: true\} ；` `
 *  **   ** 每60s或（Journal）log文件达到2GB时会做一次Checkpoint，将当前的数据持久化，产生一个新的快照；
 *      Checkpoint时会遍历所有btree，把btree的所有leaf\_page做reconcile操作，然后重新分配root\_page；  reconcile 操作：把内存里page的修改(保存在page的modify\_list中)变成磁盘page的结构写入
 *      在一个新的Checkpoint过程中，先前的Checkpoint仍然有效，即使在CheckPoint过程中出现故障，通过重启也能回复到上一次有效的Checkpoint。（加上Journal的log可进行完整数据回复）
 *      当一个新Checkpoint可用的时候，释放掉旧的Checkpoint。（同时Journal更新checkpoint offset，即可丢弃之前的journal）

**所以写请求写入journal后就可以保证Durability**

###  四、数据丢失问题 ###

Mongo早期的一些默认配置，如果不加修改使用的话，确实有可能导致一些数据丢失问题，但在后面的版本都已修正默认配置。

比如，2.0之前Journal默认是不开启状态，数据在写入内存后即刻返回应用程序，Checkpoint需要60s才持久化，这个时候发生了系统崩溃或者掉电，那么未刷盘的数据就会彻底丢失了。

写关注设置， 2.2之前默认值为\{w：0\}，不确认写入结果直接返回

对复制集来说，建议使用\{w: “majority”， j: "true"\}

[arch.jpg]: /images/20220612/04f9f0ca15b648caba0df93e5b376983.png
[image]: http://77g6ez.com1.z0.glb.clouddn.com/wt-cache2.png
[wt-snapshot.png]: http://77g6ez.com1.z0.glb.clouddn.com/wt-snapshot.png