3.MongoDB恢复探究：为什么oplogReplay参数只设置了日志应用结束时间oplogLimit，而没有设置开始时间？

（一）我的疑问

在使用MysqL数据库binlog日志基于时间点恢复数据库时，我们必须要指定binlog的开始位置和结束位置，而在MongoDB里面，如果使用oplog进行恢复，只有oploglimit参数，该参数信息如下

--oploglimit=<seconds>[:ordinal]          only include oplog entrIEs before the provIDed Timestamp

oploglimit参数定义了数据库恢复到该时间点。也就是说，MongoDB只是设置了oplog的结束位置，没有指定oplog的开始位置。那么就存在问题了，以下图为例，我在T3时刻执行了全备份，在T4时刻数据库发生了误 *** 作，当我执行恢复的时候，分为2个步骤：

补充：这里的“不受我们控制”是指在使用mongorestore重做oplog的时候，我们没办法指定开始时间。但是如果想要把oplog的开始时间控制在T3时刻，还是有办法的：使用bsondump分析全备的最后一笔数据，在备份oplog的时候，用query选项过滤掉之前的数据即可。然而，这并不是我们关心的，我所关心的，是为什么mongorestore不给出恢复 *** 作的开始时间参数。

说了那么多，把问题明确一下：

mongorestore在恢复oplog的时候，只限定了日志的结束位置，而没有开始位置，这样就会造成oplog恢复的开始位置不是T3，而是在T2，那么就会存在T2~T3这段时间数据重复 *** 作的问题，理论上会造成数据变化，为什么mongorestore不设定一个开始时间参数去避免重复 *** 作的问题呢？

本次测试在mongodb 4.2 副本集环境下进行。

（二）问题探索

（2.1）oplog日志格式解析

既然该问题可能会发生在重做oplog时，那么我们不妨先看一下oplog到底存储了什么信息。为了查看oplog日志保存了什么信息，向test集合中插入1条数据：

db.test.insert({"empno":1,"ename":"lijiaman","age":22,"address":"yunnan,kungming"});

查看test集合的数据信息

db.test.find()/* 1 */{    "_ID" : ObjectID("5f30eb58bcefe5270574cd54"),"empno" : 1.0,"ename" : "lijiaman","age" : 22.0

使用下面查询语句查看oplog日志信息：

结果如下：

oplog中各个字段的含义：

       -- "i"： insert

       --"u"： update

       --"d"： delete

       --"c"： db cmd

       --"db"：声明当前数据库 (其中ns 被设置成为=>数据库名称+ '.')

       --"n": no op,即空 *** 作，其会定期执行以确保时效性

（2.2）文档中的“_ID”字段

在上面的插入文档中，我们发现每插入一个文档，都会伴随着产生一个“_ID”字段，该字段是一个object类型，对于“_ID”，需要知道：

经过测试，发现在执行文档的DML *** 作时，会根据ID进行，我们不妨来看看DML *** 作的文档变化。

（1）插入文档，查看文档信息与oplog信息

rstest:> db.mycol.update({"ID":1},{$set:{"name":"aa"}})WriteResult({ "nMatched" : 0,"nModifIEd" : 1 })

// 每条数据的ID在当前的基础上加10
rstest:update({},{$inc:{"ID":10}},{multi:true}) WriteResult({ "nMatched" : 6 })

// 删除ID大于14的条目

rstest:> db.mycol.remove({"ID":{"$gt":14}}) WriteResult({ "nRemoved" : 2 })