Mongodb journal与oplog，究竟谁先写入？

待我称王封你为后i 2022-06-17 13:46 267阅读 0赞

# 引用文章：[http://www.mongoing.com/archives/3988][http_www.mongoing.com_archives_3988] #

# journal #

journal是Mongodb存储引擎层的概念，是一个日志用于帮助数据库在关闭后进行恢复使用的

mongodb的存储引擎有mmapv1、wiretiger、mongorocks(第三方实现，介绍： [http://blog.csdn.net/varyall/article/details/53819145][http_blog.csdn.net_varyall_article_details_53819145])

这些都支持配置journal

mongoDB所有的数据写入、读取最终都是凋存储引擎层的接口来存储、读取数据，journal是存储引擎存储数据时的一种辅助机制。

以wiretiger为例，如果不配置journal，写入wiredtiger的数据，并不会立即持久化存储；而是每分钟会做一次全量的checkpoint（storege.syncPeriodSecs配置项，

默认为1分钟），将所有的数据持久化。如果中间出现宕机，那么数据只能恢复到最近一次的checkpoint，这样最多可能丢掉1分钟的数据。

所以建议开启journal，每次写入会记录一条操作日志（通过journal可以重新构造出写入的数据）。这样即使出现宕机，启动时wiredtiger会先将

数据恢复到最近一次的checkpoint点，然后重放后续的journal操作日志来恢复。

Mongodb中journal行为主要由两个参数控制，storage.journal.enabled（是否开启）、storage.journal.commitInternalMS（设置journal刷盘的间隔，默认是100ms），用户也可以通过写入时指定writeConcern为\{j:true\}来每次写入时都确保journal刷盘

## oplog ##

oplog是mongodb主从复制层面的一个概念，通过oplog来实现复制节点间数据同步，客户端将数据写入primary，primary写入数据后会记录一条oplog，secondary从primary（或其他secondary）拉取oplog并重放，来确保复制集里每个节点存储相同的数据。

oplog在mongodb里是一个普通的capped collection,对于存储引擎来说，oplog只是一部分普通的数据而已。

## MongoDB 的一次写入 ##

MongoDB 复制集里写入一个文档时，需要修改如下数据

1.  将文档数据写入对应的集合
2.  更新集合的所有索引信息
3.  写入一条oplog用于同步

上面3个修改操作，需要确保要么都成功，要么都失败，不能出现部分成功的情况，否则

*  如果数据写入成功，但索引写入失败，那么会出现某个数据，通过全表扫描能读取到，但通过索引就无法读取
 *  如果数据、索引都写入成功，但 oplog 写入不成功，那么写入操作就不能正常的同步到备节点，出现主备数据不一致的情况

MongoDB 在写入数据时，会将上述3个操作放到一个 wiredtiger 的事务里，确保「原子性」。

beginTransaction();
    writeDataToColleciton();
    writeCollectionIndex();
    writeOplog();
    commitTransaction();

![\_2017\_03\_31\_9\_11\_53][2017_03_31_9_11_53]

wiredtiger 提交事务时，会将所有修改操作应用，并将上述3个操作写入到一条 journal 操作日志里；后台会周期性的checkpoint，将修改持久化，并移除无用的journal。

从数据布局看，oplog 与 journal 的关系

![\_2017\_03\_31\_9\_54\_35][2017_03_31_9_54_35]

## 谁先写入？？ ##

*  oplog 与 journal 是 MongoDB 里不同层次的概念，放在一起比先后本身是不合理的。
 *  oplog 在 MongoDB 里是一个普通的集合，所以 oplog 的写入与普通集合的写入并无区别。
 *  一次写入，会对应数据、索引，oplog的修改，而这3个修改，会对应一条journal操作日志。

[http_www.mongoing.com_archives_3988]: http://www.mongoing.com/archives/3988
[http_blog.csdn.net_varyall_article_details_53819145]: http://blog.csdn.net/varyall/article/details/53819145
[2017_03_31_9_11_53]: /images/20220617/c52d80b41122415fb8807d10f2f37344.png
[2017_03_31_9_54_35]: /images/20220617/973401c529014fa59dda7c7071b6da0e.png