上一篇留下了一个疑问，mongo是内存数据库吗？
我们知道，redis是内存数据库，数据都保存在内存中，对于数据的读取与操作是十分迅速的。类比可以发现，mongo不像redis把所有数据放于内存，mongo号称理论上可以存入无限多的数据，而内存可比硬盘贵多了，所以mongo的数据是存于磁盘的，对于数据的存储与持久化，mongo更像mysql。接下来聊聊mongo的journal与oplog日志。
redo/journal
MySQL的redo log和MongoDB的journal日志都是数据库存储引擎层面的WAL(Write-Ahead Logging)预写式日志，记录的是数据也的物理修改，是提高数据系统持久性的一种技术。
简单来说，redo/journal都是用于宕机后数据恢复用的，理论上机器永不宕机，redo/journal就不会发挥作用
redo日志
得益于redo日志的存在，mysql脏页不用立刻刷回磁盘中，就是宕机了数据也能从redo日志恢复，redo日志将随机写转化为了顺序写
journal日志
Mongodb-3.2已经WiredTiger设置为了默认的存储引擎
journal同理，以wiredtiger为例，如果不配置journal，写入wiredtiger的数据，并不会立即持久化存储；而是每分钟会做一次全量的checkpoint（ storage.syncPeriodSecs配置项，默认为1分钟），相当于mysql刷脏页的操作，将所有的数据持久化。如果中间出现宕机，那么数据只能恢复到最近的一次checkpoint，这样最多可能丢掉1分钟的数据。
我们知道mysql对数据的增删改有两阶段提交，即为事务成功之后，redo日志必然写成功(此时redo日志默认在内存中)，而mongo不一样，mongo的journal日志默认不和oplog日志一起写完成，需要用户自己开启journal（十分建议开启）
binlog/oplog
MySQL的binlog和MongoDB的oplog都是数据库层面的写操作对应的逻辑日志，主要用于实现数据在主从之间的同步复制以及增量备份和恢复
binlog
binlog.png
上图是MySQL主从之间是如何实现数据复制的，其中的三个重要过程是：
- 主库（Master）把数据库更改记录到binlog（图中的Binary Log）中；
- 备库（Slave）将主库上的binlog复制到自己的中继日志（Relay log）中；
- 备库读取中继日志中的事件，将其重放（Replay）到备库数据之上。
这样源源不断的复制，实现了数据在数据库节点之间的一致。
oplog
oplog是MongoDB数据库层面的概念，在复制集架构下，主备节点之间通过oplog来实现节点间的数据同步。Primary中所有的写入操作都会记录到MongoDB Oplog中，然后从库会来主库一直拉取Oplog并应用到自己的数据库中。这里的Oplog是MongoDB local数据库的一个集合，它是Capped collection；
通俗意思就是oplog是固定大小，循环使用的。所以可能需要数据恢复的业务，得设置好全量备份的时间，以防oplog已经被覆盖
oplog.png
上图是MongoDB主备之间如何实现数据复制的，其中的四个重要过程是：
- 主库（Primary）把数据库更改记录到oplog（图中的Capped Oplog集合）中；
- 备库（Secondary）把主库上的oplog拉取到自己的回放队列中（Queue）中；
- 备库读取队列中的oplog，批量回放（applyOps）到备库数据中；
- 再将队列中的Oplog写入到备库中的oplog.rs集合中。
不同于mysql的binlog只能从主节点同步数据，MongoDB支持链式复制，oplog不一定从Primary中获取，还可以从其他Secondary获取。
journal与oplog
不同于redo与binlog数据是完全分开的，一个存储物理修改，一个存储逻辑日志
journal日志中会包含binlog数据
MongoDB 复制集里写入一个文档时，需要修改如下数据
将文档数据写入对应的集合
更新集合的所有索引信息
写入一条oplog用于同步
最终存储引擎会将所有修改操作应用，并将上述3个操作写入到一条 journal 操作日志里。
其中前三条在mongo wiredtiger引擎的保证下是原子性的，但由于不是两阶段提交oplog与journal并不能保证一起写成功，也就是主从数据可能不一致，因此mongo提供了writeConcern 为 {j: ture} ，每次操作时都确保 journal 刷盘
网友评论