MongoDB 4.4 Oplog终于改成MySQL Binlog机制

Oplog注意事项  盖子集合(Capped Collections)，4.4版本之前的工作机制类似MySQL的Redo log，循环覆盖写。

工作原理：

1)存1-N增删改记录，写满了自动覆盖最旧的文档，循环写，类似Redo log。

2)Secondary在本地找到Oplog同步复制的点为27，发送请求告知Primary从序号28开始同步数据

3)Primary在本地搜索到28后，发送之后的数据给Secondary，如果未搜索到，返回请求没有此记录。
4)得到Primary没有该记录后，Secondary会执行initial sync初始化同步，先删除本地所有数据，拷贝Primary全量数据和在这之间有变更的增量数据。

场景：

假如你的一台Secondary挂了，Oplog又设置的过小，并且数据增长量又很快，Oplog此时被覆盖重写，那么只能进行initial sync全量同步。虽然在3.6版本里可以动态调整Oplog大小，但你无法准确估算Oplog啥时被覆盖重写。

在4.4版本里，Oplog可以像binlog一样，你可以根据自己的维护情况，自定义保存多久时间。

新的参数--oplogMinRetentionHours，单位小时。--oplogMinRetentionHours=24，代表保留24小时的oplog。

也可以动态修改，命令如下：

db.adminCommand({ "replSetResizeOplog" : 1,   "minRetentionHours" : 24 })

查看：

db.getSiblingDB("admin").serverStatus().oplogTruncation.oplogMinRetentionHours

参考文献：

https://docs.mongodb.com/manual/reference/command/replSetResizeOplog/#dbcmd.replSetResizeOplog