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