mongodb 中怎么利用oplog恢復(fù)時間點，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。
1.首先創(chuàng)建hezi集合，并插入10000條數(shù)據(jù)；
MongoDB Enterprise liuhe_rs:PRIMARY>use liuwenhe
MongoDB Enterprise liuhe_rs:PRIMARY>for (var i = 0; i < 100000; i++) { db.hezi.insert({id: i}); }
MongoDB Enterprise liuhe_rs:PRIMARY> db.hezi.count();
100000
2.執(zhí)行備份操作，使用參數(shù) --oplog ，會在備份路徑下產(chǎn)生oplog.bson文件
[mongod@beijing-fuli-hadoop-01 backup]$ mongodump -h 10.9.21.179 -u liuwenhe -p
liuwenhe --authenticationDatabase admin --oplog -o /data/mongodb/backup/
假設(shè)備份開始時間為 A 結(jié)束時間為B
3.等備份完成后，如果此時業(yè)務(wù)又insert了數(shù)據(jù)：
MongoDB Enterprise liuhe_rs:PRIMARY> db.hezi.insert({id: 100001});
WriteResult({ "nInserted" : 1 })
MongoDB Enterprise liuhe_rs:PRIMARY> db.hezi.count();
100001
4.在時間 C點，模擬誤刪除操作
MongoDB Enterprise liuhe_rs:PRIMARY> db.hezi.remove({})
WriteResult({ "nRemoved" : 100001 })
MongoDB Enterprise liuhe_rs:PRIMARY> db.hezi.count();
0
5.那么怎么來恢復(fù)這個表呢？
這種情況下，應(yīng)該首先停止業(yè)務(wù)，避免由于業(yè)務(wù)量大，導(dǎo)致把oprlog給覆蓋了，因為如果
oprlog被覆蓋了，那么你就無法恢復(fù)出db.hezi.insert({id: 100001})這條數(shù)據(jù)，因為這條數(shù)據(jù)
是在你備份完成后插入的數(shù)據(jù)，所以你需要立刻把oplog.rs集合給dump出來以便于進(jìn)行時
間點恢復(fù)，
所以分兩種情況具體如下：
情況一：
你備份開始的時間點A 到 你誤刪除的時間點C 這段時間的oplog.rs的數(shù)據(jù)沒有被覆蓋
那么就肯定能恢復(fù)出所有的數(shù)據(jù)！直接用你后來備份的oplog.rs替換你之前全備份的產(chǎn)生的
oplog.bson文件！
情況二：（分成兩種情況）
如果你備份開始的時間點A 到 你誤刪除的時間點C 這段時間的oplog.rs的數(shù)據(jù)被覆蓋了，
那么你就只能先恢復(fù)你的全備，然后再從oplog.rs里面盡可能找到更多的關(guān)于這個集合的
操作，然后應(yīng)用，能不能全部恢復(fù)出數(shù)據(jù)，就看運(yùn)氣了，這里又有兩種情況：
情況1：備份結(jié)束B到誤刪除C 這段時間內(nèi)的oplog.rs沒有被覆蓋，那么就可以恢復(fù)出所有的數(shù)據(jù)
情況2：備份結(jié)束B到誤刪除C 這段時間內(nèi)的oplog.rs被覆蓋，那么就只能期待關(guān)于這個集合的操作
的oplog沒有被覆蓋，這樣才能恢復(fù)出所有的數(shù)據(jù)！
怎么去分辨到底有沒有被覆蓋呢？
首先在你備份的機(jī)器上看，可以看出oplogs的開始和結(jié)束時間，當(dāng)然這不一定準(zhǔn)確，
MongoDB Enterprise liuhe_rs:PRIMARY> rs.printReplicationInfo()
configured oplog size: 51200MB
log length start to end: 1299939secs (361.09hrs)
oplog first event time: Sat Nov 16 2019 16:53:17 GMT+0800 (CST)
oplog last event time: Sun Dec 01 2019 17:58:56 GMT+0800 (CST)
now: Sun Dec 01 2019 17:59:02 GMT+0800 (CST)
最好還是從你單獨(dú)備份集合oplog.rs的備份文件oplog.rs.bson中去判斷：
格式化文件oplog.rs.bson，以便于查看時間
[mongod@beijing-fuli-hadoop-04 local]$ bsondump oplog.rs.bson >12
看備份中的oplog的開始時間
[mongod@beijing-fuli-hadoop-04 local]$ cat 12 | head
{"ts":{"$timestamp":{"t":1575040546,"i":1}},"t":{"$numberLong":"7"},"h":{"$numberLong":"-8378285387564165709"},"v":2,"op":"n","ns":"","wall":{"$date":"2019-11-29T15:15:46.661Z"},"o":{"msg":"Reconfig set","version":26}}
看備份中的oplog的結(jié)束時間
[mongod@beijing-fuli-hadoop-04 local]$ cat 12 | tail -n 1
{"ts":{"$timestamp":{"t":1575040546,"i":1}},"t":{"$numberLong":"7"},"h":{"$numberLong":"-8378285387564165709"},"v":2,"op":"n","ns":"","wall":{"$date":"2019-11-29T15:15:46.661Z"},"o":{"msg":"Reconfig set","version":26}}
同理再去查看全備份的產(chǎn)生的oplog.bson中的開始時間和結(jié)束時間！就可以判斷出有沒有被覆蓋了！
情況1：
1）dump出集合oplog.rs的數(shù)據(jù)
[mongod@beijing-fuli-hadoop-01 local]$ mongodump -h 10.9.21.179 -u liuwenhe -p liuwenhe --authenticationDatabase admin -d local -c oplog.rs -o /data/mongodb/liuwenhe/
[mongod@beijing-fuli-hadoop-01 local]$ pwd
/data/mongodb/liuwenhe/local
[mongod@beijing-fuli-hadoop-01 local]$ ll
total 60308
-rw-rw-r-- 1 mongod mongod 61751065 Nov 29 19:42 oplog.rs.bson
-rw-rw-r-- 1 mongod mongod 124 Nov 29 19:42 oplog.rs.metadata.json
2）然后找到刪除hezi集合的開始時間, 當(dāng)你刪除某個集合的時候，她在oplogs中是一條一條的刪除的！這個你可以使用bsondump格式化看看！
[mongod@beijing-fuli-hadoop-01 local]$ bsondump oplog.rs.bson | grep "\"op\":\"d\"" | grep liuwenhe.hezi |head
{"ts":{"$timestamp":{"t":1575025894,"i":1}},"t":{"$numberLong":"6"},"h":{"$numberLong":"2211936654694340159"},"v":2,"op":"d","ns":"liuwenhe.hezi","ui":{"$binary":"GG4MuSZBQpm4anq5TBp00Q==","$type":"04"},"wall":{"$date":"2019-11-29T11:11:34.499Z"},"o":{"_id":{"$oid":"5de0fb7cb54dce214bb40c7b"}}}
3）需要把 前面?zhèn)浞莸膐plog.rs.bson文件替換全備份的文件中的oplog.bson文件，
這里的oplog.rs.bson其實就是我們需要的oplog.bson。因此把它重命名后放到合適的位置！
[mongod@beijing-fuli-hadoop-03 /data/mongodb/backup/backup]$ rm -f oplog.bson
[mongod@beijing-fuli-hadoop-03 /data/mongodb/backup/backup]$mv oplog.rs.bson oplog.bson
其中oplog.rs.bson是你前面單獨(dú)備份的oplog.rs， 而oplog.bson是你全備份中帶參數(shù) --oplog產(chǎn)生的文件；
4）在另一個空閑實例上恢復(fù)出之前的全備份：
先把備份從21.114copy到21.115特定的目錄中：
scp -r backup/ mongod@10.9.21.115:/data/mongodb/backup/
然后進(jìn)行恢復(fù)：
[mongod@beijing-fuli-hadoop-03 /data]$ mongorestore -h 10.9.21.115 -u liuwenhe -p liuwenhe --oplogReplay --oplogLimit "1575025894:1" --authenticationDatabase admin --dir /data/mongodb/backup/backup/
其中1575025894即是$timestamp中的"t"，1即是$timestamp中的"i"。這樣配置后oplog將會
重放到這個時間點以前，即正好避開了第一條刪除語句及其后面的操作，數(shù)據(jù)庫停留在災(zāi)難
前狀態(tài)
驗證確實恢復(fù)出來了：
MongoDB Enterprise > db.hezi.count()
100000
5）把恢復(fù)出來的數(shù)據(jù)在恢復(fù)到生產(chǎn)上去：
在21.115上備份：
mongodump -h 10.9.21.115 -u liuwenhe -p liuwenhe -d liuwenhe -dliuwenhe -c hezi --authenticationDatabase admin -o /data/mongodb/
在21.115上直接恢復(fù)，前提網(wǎng)絡(luò)通，如果不通的話，先把備份文件copy到生產(chǎn)上。然后恢復(fù)：
[mongod@beijing-fuli-hadoop-04 li]$ mongorestore -h 10.9.21.114 -u liuwenhe -p liuwenhe -d liuwenhe -c hehe --noIndexRestore --authenticationDatabase admin --dir /data/mongodb/backup/li/hezi.bson
情況2中的第一種情況：
備份結(jié)束B到誤刪除C 這段時間內(nèi)的oplog.rs沒有被覆蓋，那么就可以恢復(fù)出所有的數(shù)據(jù)，具體
恢復(fù)過程如下：
1.恢復(fù)一致性全備份：
[mongod@beijing-fuli-hadoop-03 /data]$ mongorestore -h 10.9.21.115 -u liuwenhe -p liuwenhe --oplogReplay --authenticationDatabase admin --dir /data/mongodb/backup/backup/
2.然后再繼續(xù)增量恢復(fù)oplog,從備份的oplog.rs文件中找到刪除hezi這個集合的時間點，因為opglog
的冪等性，可以重復(fù)執(zhí)行也不會造成數(shù)據(jù)不一致，所以沒必要在導(dǎo)出oplog.rs的時候選擇增量導(dǎo)出；
mongorestore -h 10.9.21.115 -u liuwenhe -p liuwenhe --oplogReplay --oplogLimit "1575025894:1" --authenticationDatabase admin --dir /data/mongodb/backup/backup/local/oplog.rs.bson
情況2中的第二種情況：
備份結(jié)束B到誤刪除C 這段時間內(nèi)的oplog.rs被覆蓋，那么就只能期待關(guān)于這個集合的操作
的oplog沒有被覆蓋，這樣才能恢復(fù)出所有的數(shù)據(jù)！坦白講這種情況下，沒法確認(rèn)到底關(guān)于
這個集合的操作的oplogs有沒有被覆蓋，只能先恢復(fù)看了，過程同情況2中的第一種情況；
綜上所述：
mongodb的時間點恢復(fù)的過程類似于mysql借助binlog的過程，但是區(qū)別是
mysql需要找到具體的 gtid點，增量恢復(fù)，但是mongodb的oplog是可以多次執(zhí)行，這樣就使得
mongodb 借助oprlog的時候操作簡單些；
看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。
重慶分公司
重慶分公司
