MongoDB 利用 oplog 恢复数据操作手册 -- cnDBA.cn

1 利用oplog 增量恢复概述

在之前的博客，我们介绍了oplog 的相关内容，如下：

MongoDB 4.4 中 journal 和 oplog 日志说明
https://www.cndba.cn/dave/article/107979

MongoDB 估计Oplog大小方法
https://www.cndba.cn/dave/article/108008

MongoDB 备份与恢复说明
https://www.cndba.cn/dave/article/107972

MongoDB 4.4 oplog 内容格式说明
https://www.cndba.cn/dave/article/108035
http://www.cndba.cn/dave/article/108043

在实际运维中，当发生误操作，比如drop 集合和数据库的情况，那么就可以利用全备份 + oplog 进行数据的恢复。

这种恢复方法有2个注意的点：

Oplog 要足够大，里面记录的数据要覆盖全备的周期。假设每周六晚上全备，那么oplog 要保存从周六备份以后的所有数据。 Oplog 的大小和保留时间调整，之前的博客有说明，这里不再重复描述。
确定误操作的时间。这里也有两种方法：

方法1：直接在local 库里查询oplog.rs集合：

db.oplog.rs.find({“ns” : “cndba.$cmd”, “op”: “c”})

方法2：先全部dump 出全部的oplog，然后利用bsondump 从oplog 的导出文件中搜索：http://www.cndba.cn/dave/article/108043

bsondump /root/mongodb_dir/local/oplog.rs.bson | grep “/”op/”:/”c/”” | grep “drop”http://www.cndba.cn/dave/article/108043

从查询时间时间上看，肯定是直接查库效率最高。从bsondump 文件查询效率是较低的。

恢复的大致流程是：

确定误操作的时间
利用上一步确定的时间，导出oplog
利用之前的全备文件恢复数据库。
在全备基础上重演oplog 数据。
验证数据。

2 操作示例

2.1 操作方法1演示：应用过滤导出后的oplog

2.1.1 当前环境

[dave@www.cndba.cn ~]# mongo_conn 27017
MongoDB shell version v5.0.8

rs0:PRIMARY> show dbs;
admin   0.000GB
cndba   0.003GB
config  0.000GB
local   1.750GB
m201    0.132GB
rs0:PRIMARY> 
rs0:PRIMARY> use m201
switched to db m201
rs0:PRIMARY> show collections;
people
restaurants
rs0:PRIMARY> db.restaurants.find().count()
1000000
rs0:PRIMARY>

2.1.2 全备数据库

[dave@www.cndba.cn backup]# mongodump --username=root --password=root --host=127.0.0.1 --port=27017 --authenticationDatabase admin  --oplog --out /data/mongodb/backup
2022-05-31T11:43:24.950+0800    writing admin.system.users to /data/mongodb/backup/admin/system.users.bson
2022-05-31T11:43:24.951+0800    done dumping admin.system.users (2 documents)
2022-05-31T11:43:24.952+0800    writing admin.system.version to /data/mongodb/backup/admin/system.version.bson
2022-05-31T11:43:24.953+0800    done dumping admin.system.version (2 documents)
2022-05-31T11:43:24.954+0800    writing m201.restaurants to /data/mongodb/backup/m201/restaurants.bson
2022-05-31T11:43:24.956+0800    writing m201.people to /data/mongodb/backup/m201/people.bson
2022-05-31T11:43:24.961+0800    writing cndba.ustc to /data/mongodb/backup/cndba/ustc.bson
2022-05-31T11:43:24.962+0800    done dumping cndba.ustc (2 documents)
2022-05-31T11:43:24.962+0800    writing config.external_validation_keys to /data/mongodb/backup/config/external_validation_keys.bson
2022-05-31T11:43:24.963+0800    done dumping config.external_validation_keys (0 documents)
2022-05-31T11:43:24.965+0800    writing config.tenantMigrationRecipients to /data/mongodb/backup/config/tenantMigrationRecipients.bson
2022-05-31T11:43:24.965+0800    done dumping config.tenantMigrationRecipients (0 documents)
2022-05-31T11:43:24.966+0800    writing config.tenantMigrationDonors to /data/mongodb/backup/config/tenantMigrationDonors.bson
2022-05-31T11:43:24.966+0800    done dumping config.tenantMigrationDonors (0 documents)
2022-05-31T11:43:24.967+0800    writing cndba.user to /data/mongodb/backup/cndba/user.bson
2022-05-31T11:43:25.128+0800    done dumping cndba.user (100000 documents)
2022-05-31T11:43:25.273+0800    done dumping m201.people (50474 documents)
2022-05-31T11:43:26.760+0800    done dumping m201.restaurants (1000000 documents)
2022-05-31T11:43:26.770+0800    writing captured oplog to
2022-05-31T11:43:26.786+0800            dumped 1 oplog entry
[dave@www.cndba.cn backup]# pwd
/data/mongodb/backup
[dave@www.cndba.cn backup]# ll
total 4
drwxr-xr-x 2 root root 128 May 31 11:43 admin
drwxr-xr-x 2 root root  92 May 31 11:43 cndba
drwxr-xr-x 2 root root 251 May 31 11:43 config
drwxr-xr-x 2 root root 110 May 31 11:43 m201
-rw-r--r-- 1 root root 103 May 31 11:43 oplog.bson
[dave@www.cndba.cn backup]#

这里要注意几点：

—oplog参数：会记录备份过程中的数据变化，并以”.bson”格式保存下来。
local 数据库不会进行备份。

2.1.3 进行操作

rs0:PRIMARY> use m201
switched to db m201
rs0:PRIMARY> show tables;
people
restaurants
创建测试表：
rs0:PRIMARY> var docs=db.people.find()
rs0:PRIMARY> docs.forEach(function(d){db.ustc.insert(d)});
rs0:PRIMARY> db.ustc.find().count()
50474
rs0:PRIMARY>

rs0:PRIMARY> db.ustc.findOne()
{
        "_id" : ObjectId("57d7a121fa937f710a7d4875"),
        "last_name" : "Perry",
        "quote" : "Tempore sunt quae temporibus in nostrum.",
        "job" : "Environmental consultant",
        "ssn" : "248-70-8696",
        "address" : {
                "city" : "Jamesfurt",
                "street" : "4961 Obrien Keys",
                "zip" : "19133"
        },
        "first_name" : "Trevor",
        "company_id" : ObjectId("57d7a121fa937f710a7d486d"),
        "employer" : "Terry and Sons",
        "birthday" : ISODate("2013-03-05T18:59:23Z"),
        "email" : "teresabrown@yahoo.com"
}
rs0:PRIMARY> db.ustc.deleteMany({ "last_name" : "Perry"});
{ "acknowledged" : true, "deletedCount" : 92 }
rs0:PRIMARY> db.ustc.find().count()
50382
rs0:PRIMARY> db.ustc.drop()
true
rs0:PRIMARY>

2.1.4 备份oplog 日志

这里可以是直接全备份所有oplog，也可以根据误操作的时间来导出。

我们这里根据时间导出oplog：

rs0:PRIMARY> use local
switched to db local
rs0:PRIMARY> db.oplog.rs.find({"ns" : "m201.$cmd", "op": "c"})
rs0:PRIMARY> db.oplog.rs.find({"op": "c"})
……
{ "op" : "c", "ns" : "m201.$cmd", "ui" : UUID("ddedd93a-098f-40ea-90c7-dc10cb8510aa"), "o" : { "drop" : "ustc" }, "o2" : { "numRecords" : 50382 }, "ts" : Timestamp(1654063757, 1), "t" : NumberLong(21), "v" : NumberLong(2), "wall" : ISODate("2022-06-01T06:09:17.893Z") }
……

查找最近5次删除：

rs0:PRIMARY> db.oplog.rs.find({“ns” : “cndba.$cmd”, “op”: “c”}).sort({“ts”:-1}).limit(5)

这里我们获取到drop 的时间是：Timestamp(1654063757, 1)。

这里还需要指定导出oplog 开始的时间。

查看当前备份时间：

[dave@www.cndba.cn ~]# cd /data/mongodb/backup
[dave@www.cndba.cn backup]# ll
total 4
drwxr-xr-x 2 root root 128 Jun  1 13:54 admin
drwxr-xr-x 2 root root  92 Jun  1 13:54 cndba
drwxr-xr-x 2 root root 251 Jun  1 13:54 config
drwxr-xr-x 2 root root 110 Jun  1 13:54 m201
-rw-r--r-- 1 root root 206 Jun  1 13:54 oplog.bson
[dave@www.cndba.cn backup]#

我们将开始的时间设置为2022-06-01 13:50:00，转换timestamp为：1654062600

根据开始和截止时间来导出oplog：

[dave@www.cndba.cn oplog_backup]# mongodump --username=root --password=root --host=127.0.0.1 --port=27017 --authenticationDatabase admin -d local -c "oplog.rs"  -q '{"ts":{"$gt":{"$timestamp":{"t":1654062600, "i":1}},"$lt": {"$timestamp":{"t":1654063757, "i":1}}}}' --out /data/mongodb/oplog_backup
2022-06-01T20:54:36.134+0800    writing local.oplog.rs to /data/mongodb/oplog_backup/local/oplog.rs.bson
2022-06-01T20:54:36.339+0800    done dumping local.oplog.rs (50675 documents)
[dave@www.cndba.cn oplog_backup]#

这里有2个细节：

时间格式要注意。
Oplog 的备份目录不能放在全备目录下，因为会生成一个local 的目录，会导致全库恢复失败。

注意这里时间格式稍微调整了一下：

Mongodump Failed: error parsing query as Extended JSON 错误解决方法
https://www.cndba.cn/dave/article/108036

删除备份目录下的local 文件之后，在进行恢复，否则会报如下错误：http://www.cndba.cn/dave/article/108043

MongoDB 4.4 mongorestore can’t drop live oplog while replicating 错误解决方法
https://www.cndba.cn/dave/article/108037

这里导出oplog 一定要指定2个时间：开始和结束时间。开始时间是全备开始时间的稍前一点的时间，结束时间是误操作时间，否则进行oplog 重演时可能会报如下错误：

MongoDB 重演 oplog 报错： cannot apply insert or update operation on a non-existent namespace 错误解决方法
https://www.cndba.cn/dave/article/108041

其实这里还有另外一个知识点，就是oplog中的每个操作都是幂等的。也就是说，在目标库中应用oplog时，无论应用一次还是多次都是相同的结果。所以虽然我们导出oplog

幂等性
https://www.cndba.cn/dave/article/5033

2.1.5 恢复全备

[dave@www.cndba.cn backup]# pwd
/data/mongodb/backup
[dave@www.cndba.cn backup]# ls
admin  cndba  config  m201  oplog.bson
[dave@www.cndba.cn backup]# ll
total 4
drwxr-xr-x 2 root root 128 May 31 11:43 admin
drwxr-xr-x 2 root root  92 May 31 11:43 cndba
drwxr-xr-x 2 root root 251 May 31 11:43 config
drwxr-xr-x 2 root root 110 May 31 11:43 m201
-rw-r--r-- 1 root root 103 May 31 11:43 oplog.bson
[dave@www.cndba.cn backup]#
[dave@www.cndba.cn oplog_backup]# mongorestore --username=root --password=root --host=127.0.0.1 --port=27017 --authenticationDatabase admin --drop  --oplogReplay /data/mongodb/backup
2022-06-01T14:16:40.596+0800    preparing collections to restore from
2022-06-01T14:16:40.598+0800    don't know what to do with file "/data/mongodb/backup/.pbm.init", skipping...
2022-06-01T14:16:40.638+0800    reading metadata for m201.people from /data/mongodb/backup/m201/people.metadata.json
2022-06-01T14:16:40.639+0800    reading metadata for m201.restaurants from /data/mongodb/backup/m201/restaurants.metadata.json
2022-06-01T14:16:40.640+0800    reading metadata for cndba.user from /data/mongodb/backup/cndba/user.metadata.json
2022-06-01T14:16:40.641+0800    reading metadata for cndba.ustc from /data/mongodb/backup/cndba/ustc.metadata.json
2022-06-01T14:16:40.641+0800    reading metadata for config.external_validation_keys from /data/mongodb/backup/config/external_validation_keys.metadata.json
……
2022-06-01T14:17:34.863+0800    1150476 document(s) restored successfully. 0 document(s) failed to restore.
[dave@www.cndba.cn oplog_backup]#

2.1.6 重演oplog

mongorestore本身是用来恢复bson文件的同时顺便重放oplog的。现在我们没有bson要恢复，只有oplog要重放，所以需要点小花招来欺骗mongorestore，那就是用一个空文件夹：

[dave@www.cndba.cn oplog_backup]# mkdir empty
[dave@www.cndba.cn oplog_backup]# mongorestore --username=root --password=root --host=127.0.0.1 --port=27017 --authenticationDatabase admin --oplogReplay --oplogFile /data/mongodb/oplog_backup/local/oplog.rs.bson --dir empty
2022-06-01T20:56:01.139+0800    preparing collections to restore from
2022-06-01T20:56:01.140+0800    replaying oplog
2022-06-01T20:56:01.140+0800    skipping applying the config.system.sessions namespace in applyOps
2022-06-01T20:56:01.140+0800    skipping applying the config.system.sessions namespace in applyOps
2022-06-01T20:56:01.141+0800    skipping applying the config.system.sessions namespace in applyOps
2022-06-01T20:56:04.148+0800    oplog  1.44MB
2022-06-01T20:56:07.139+0800    oplog  2.76MB
2022-06-01T20:56:10.139+0800    oplog  4.19MB
2022-06-01T20:56:13.139+0800    oplog  5.75MB
2022-06-01T20:56:16.149+0800    oplog  7.22MB
2022-06-01T20:56:19.149+0800    oplog  8.74MB
2022-06-01T20:56:22.148+0800    oplog  9.90MB
2022-06-01T20:56:25.139+0800    oplog  11.5MB
2022-06-01T20:56:28.150+0800    oplog  13.0MB
2022-06-01T20:56:31.139+0800    oplog  14.4MB
2022-06-01T20:56:34.139+0800    oplog  15.8MB
2022-06-01T20:56:37.139+0800    oplog  17.2MB
2022-06-01T20:56:40.139+0800    oplog  18.6MB
2022-06-01T20:56:43.141+0800    oplog  19.9MB
2022-06-01T20:56:46.139+0800    oplog  21.3MB
2022-06-01T20:56:49.139+0800    oplog  22.7MB
2022-06-01T20:56:51.938+0800    applied 50567 oplog entries
2022-06-01T20:56:51.938+0800    oplog  23.9MB
2022-06-01T20:56:51.938+0800    no indexes to restore for collection m201.ustc
2022-06-01T20:56:51.938+0800    0 document(s) restored successfully. 0 document(s) failed to restore.
[dave@www.cndba.cn oplog_backup]#

注：

我们这里是采用全备 + oplog 分开应用了。实际上，还有另外一种方法，就是直接将oplog 的备份文件覆盖掉全备下的oplog.bson 备份，这样全备+oplog 的恢复可以一条命令搞定，不用在执行2次了：http://www.cndba.cn/dave/article/108043

[dave@www.cndba.cn backup]# pwd
/data/mongodb/backup
[dave@www.cndba.cn backup]# ll
total 4
drwxr-xr-x 2 root root 128 May 31 11:43 admin
drwxr-xr-x 2 root root  92 May 31 11:43 cndba
drwxr-xr-x 2 root root 251 May 31 11:43 config
drwxr-xr-x 2 root root 110 May 31 11:43 m201
-rw-r--r-- 1 root root 103 May 31 11:43 oplog.bson
[dave@www.cndba.cn backup]#

当然这里在复制的时候，还需要进行重命名的操作，如果导出的是同一个目录，还需要删除掉local的目录，如下：

[dave@www.cndba.cn bac local kup]# cp oplog.rs.bson ../oplog.bson       #会将之前全备的oplog.bson一样的内容自动覆盖
[dave@www.cndba.cn backup]#rm -rf /mongodb/backup/local/       #把local目录删掉，因为local并不是我们备份数据中的一部分

2.1.7 验证数据

rs0:PRIMARY> use m201
switched to db m201
rs0:PRIMARY> db.ustc.find().count()
50382
rs0:PRIMARY>

数据和drop 之前保持一致。利用oplog 恢复成功。

2.2 操作方法2演示：应用没有过滤导出的oplog

2.2.1 导出所有oplog

如果是直接导出所有oplog，命令如下：

[dave@www.cndba.cn oplog_backup]# mongodump --username=root --password=root --host=127.0.0.1 --port=27017 --authenticationDatabase admin -d local -c oplog.rs  -o /data/mongodb/oplog_backup
2022-06-01T21:14:09.248+0800    writing local.oplog.rs to /data/mongodb/oplog_backup/local/oplog.rs.bson
2022-06-01T21:14:12.228+0800    local.oplog.rs  711856
2022-06-01T21:14:15.228+0800    local.oplog.rs  1519775
2022-06-01T21:14:18.230+0800    local.oplog.rs  2321569
2022-06-01T21:14:21.228+0800    local.oplog.rs  3177290
2022-06-01T21:14:24.228+0800    local.oplog.rs  3910392
2022-06-01T21:14:27.228+0800    local.oplog.rs  4613630
2022-06-01T21:14:30.228+0800    local.oplog.rs  5478486
2022-06-01T21:14:30.944+0800    local.oplog.rs  5686741
2022-06-01T21:14:30.944+0800    done dumping local.oplog.rs (5686741 documents)
[dave@www.cndba.cn oplog_backup]#

2.2.2 替换oplog 文件

将备份出来的oplog 文件替换掉全备时生成的备份oplog 文件。

[dave@www.cndba.cn local]# pwd
/data/mongodb/oplog_backup/local
[dave@www.cndba.cn local]# cd ../../backup/
[dave@www.cndba.cn backup]# ls
admin  cndba  config  m201  oplog.bson
[dave@www.cndba.cn backup]# mv oplog.bson oplog.bson.bak
[dave@www.cndba.cn backup]# cp ../oplog_backup/local/oplog.rs.bson oplog.bson
[dave@www.cndba.cn backup]# ls
admin  cndba  config  m201  oplog.bson  oplog.bson.bak
[dave@www.cndba.cn backup]# ll
total 2416092
drwxr-xr-x 2 root root        128 Jun  1 13:54 admin
drwxr-xr-x 2 root root         92 Jun  1 13:54 cndba
drwxr-xr-x 2 root root        251 Jun  1 13:54 config
drwxr-xr-x 2 root root        110 Jun  1 13:54 m201
-rw-r--r-- 1 root root 2474072881 Jun  1 21:20 oplog.bson
-rw-r--r-- 1 root root        206 Jun  1 13:54 oplog.bson.bak
[dave@www.cndba.cn backup]#

2.2.3 恢复全备数据库+ 重演最新的oplog

因为我们替换了全备时的oplog，所以这里我们只需要在恢复时指定重演oplog的截止时间即可。

这里的时间可以利用上节local 库里的查询方法，也可以直接从oplog的dump中搜索：

[dave@www.cndba.cn ~]# bsondump /data/mongodb/oplog_backup/local/oplog.rs.bson | grep "/"op/":/"c/""  |  grep "drop" |grep ustc
{"op":"c","ns":"cndba.$cmd","ui":{"$binary":{"base64":"vuLF31/RTPyi472zNHmx5Q==","subType":"04"}},"o":{"drop":"ustc"},"o2":{"numRecords":{"$numberInt":"2"}},"ts":{"$timestamp":{"t":1653957788,"i":4}},"t":{"$numberLong":"17"},"v":{"$numberLong":"2"},"wall":{"$date":{"$numberLong":"1653957788712"}}}
{"op":"c","ns":"cndba.$cmd","ui":{"$binary":{"base64":"qSfpzlXuSm2gHzMC4PauMw==","subType":"04"}},"o":{"drop":"ustc"},"o2":{"numRecords":{"$numberInt":"2"}},"ts":{"$timestamp":{"t":1653969164,"i":4}},"t":{"$numberLong":"18"},"v":{"$numberLong":"2"},"wall":{"$date":{"$numberLong":"1653969164348"}}}
{"op":"c","ns":"cndba.$cmd","ui":{"$binary":{"base64":"5qCke6xtQPSNdwOllW9DTA==","subType":"04"}},"o":{"drop":"ustc"},"o2":{"numRecords":{"$numberInt":"2"}},"ts":{"$timestamp":{"t":1653989002,"i":5}},"t":{"$numberLong":"21"},"v":{"$numberLong":"2"},"wall":{"$date":{"$numberLong":"1653989002730"}}}
2022-06-01T21:34:29.651+0800    5686741 objects found
{"op":"c","ns":"m201.$cmd","ui":{"$binary":{"base64":"3e3ZOgmPQOqQx9wQy4UQqg==","subType":"04"}},"o":{"drop":"ustc"},"o2":{"numRecords":{"$numberInt":"50382"}},"ts":{"$timestamp":{"t":1654063757,"i":1}},"t":{"$numberLong":"21"},"v":{"$numberLong":"2"},"wall":{"$date":{"$numberLong":"1654063757893"}}}
{"op":"c","ns":"cndba.$cmd","ui":{"$binary":{"base64":"G8IQbCJTQeWQB27sd8Ru5A==","subType":"04"}},"o":{"drop":"ustc"},"o2":{"numRecords":{"$numberInt":"2"}},"ts":{"$timestamp":{"t":1654064200,"i":4}},"t":{"$numberLong":"21"},"v":{"$numberLong":"2"},"wall":{"$date":{"$numberLong":"1654064200686"}}}
[dave@www.cndba.cn ~]#

开始恢复数据库：

[dave@www.cndba.cn backup]# mongorestore --username=root --password=root --host=127.0.0.1 --port=27017 --authenticationDatabase admin --drop  --oplogReplay  --oplogLimit "1654063757:1" /data/mongodb/backup
2022-06-01T21:23:24.582+0800    preparing collections to restore from
2022-06-01T21:23:24.583+0800    don't know what to do with file "/data/mongodb/backup/.pbm.init", skipping...
2022-06-01T21:23:24.583+0800    don't know what to do with file "/data/mongodb/backup/oplog.bson.bak", skipping...
2022-06-01T21:23:24.586+0800    reading metadata for m201.people from /data/mongodb/backup/m201/people.metadata.json
2022-06-01T21:23:24.587+0800    reading metadata for m201.restaurants from /data/mongodb/backup/m201/restaurants.metadata.json
2022-06-01T21:23:24.588+0800    reading metadata for cndba.user from /data/mongodb/backup/cndba/user.metadata.json
2022-06-01T21:23:24.589+0800    reading metadata for cndba.ustc from /data/mongodb/backup/cndba/ustc.metadata.json
2022-06-01T21:23:24.590+0800    reading metadata for config.external_validation_keys from /data/mongodb/backup/config/external_validation_keys.metadata.json
……
2022-06-01T21:32:54.588+0800    oplog  201MB
2022-06-01T21:32:57.593+0800    oplog  201MB
2022-06-01T21:33:00.582+0800    oplog  202MB
2022-06-01T21:33:03.600+0800    oplog  202MB
2022-06-01T21:33:06.583+0800    oplog  203MB
……
2022-06-01T22:05:48.582+0800    oplog  1003MB
2022-06-01T22:05:51.608+0800    oplog  1004MB
2022-06-01T22:05:54.592+0800    oplog  1006MB
……
2022-06-01T22:38:49.238+0800    restoring indexes for collection config.tenantMigrationDonors from metadata
2022-06-01T22:38:49.238+0800    index: &idx.IndexDocument{Options:primitive.M{"expireAfterSeconds":0, "name":"TenantMigrationDonorTTLIndex", "v":2}, Key:primitive.D{primitive.E{Key:"expireAt", Value:1}}, PartialFilterExpression:primitive.D(nil)}
2022-06-01T22:38:53.387+0800    1150476 document(s) restored successfully. 0 document(s) failed to restore.

重演过程一直在输出的是oplog 应用的进度，我们oplog 有2.4G，在我的测试环境，大概是3秒/M 的速度，比较慢。

[dave@www.cndba.cn backup]# ll -lh
total 2.4G
drwxr-xr-x 2 root root  128 Jun  1 13:54 admin
drwxr-xr-x 2 root root   92 Jun  1 13:54 cndba
drwxr-xr-x 2 root root  251 Jun  1 13:54 config
drwxr-xr-x 2 root root  110 Jun  1 13:54 m201
-rw-r--r-- 1 root root 2.4G Jun  1 21:20 oplog.bson
-rw-r--r-- 1 root root  206 Jun  1 13:54 oplog.bson.bak
[dave@www.cndba.cn backup]#

开始时间：2022-06-01T21:23:24.582+0800
结束时间：2022-06-01T22:38:53.387+0800

在我的测试环境上，2.4G的oplog 重演花了75分钟，但也没有报分开处理时集合不存在的错误。

通过替换替换oplog 文件的方法，可以在一个操作中完成全备恢复和oplog 重演的操作。注意这里，我们只是设置了oplog 的截止时间。所以通过对比，也可以看出，如果是恢复全备+重演oplog 同时进行，那么对与oplog 导出开始时间并不重要，但是，如果oplog 很大，明显会浪费很多的时间。所以从恢复的效率角度来看，在导出oplog 时，强制建议指定开始时间和结束时间。

2.2.4 验证数据

rs0:PRIMARY> use m201
switched to db m201
rs0:PRIMARY> db.ustc.find().count()
50382

数据也是一致的。 http://www.cndba.cn/dave/article/108043

3 小结

通过测试，可以验证最佳的操作方法，步骤如下：http://www.cndba.cn/dave/article/108043

在local 库中查询oplog.rs 确定误操作的时间。
指定开始时间和结束时间来导出oplog。导出全部oplog 是非常不建议的方法，不仅导出慢，在应用的时候，还会重演很多无用的操作，浪费很多的时间。
如果是希望在全备恢复的同时重演oplog，那么就用导出的olog 替换到全备文件中的oplog，然后进行恢复。
如果是全备恢复和重演oplog 分开进行，那么在重演时需要采用empty目录的方式来满足mongorestore的条件。

也就是操作方法1的演示：应用过滤导出后的oplog。

当然，在生产环境进行恢复时，可以考虑在新的环境上恢复。

签到成功

CNDBA社区