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