mongodb中怎么利用oplog恢复时间点-创新互联
mongodb 中怎么利用oplog恢复时间点,很多新手对此不是很清楚,为了帮助大家解决这个难题,下面小编将为大家详细讲解,有这方面需求的人可以来学习下,希望你能有所收获。
创新互联凭借在网站建设、网站推广领域领先的技术能力和多年的行业经验,为客户提供超值的营销型网站建设服务,我们始终认为:好的营销型网站就是好的业务员。我们已成功为企业单位、个人等客户提供了网站设计、网站建设服务,以良好的商业信誉,完善的服务及深厚的技术力量处于同行领先地位。1.首先创建hezi集合,并插入10000条数据;
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.执行备份操作,使用参数 --oplog ,会在备份路径下产生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/
假设备份开始时间为 A 结束时间为B
3.等备份完成后,如果此时业务又insert了数据:
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.那么怎么来恢复这个表呢?
这种情况下,应该首先停止业务,避免由于业务量大,导致把oprlog给覆盖了,因为如果
oprlog被覆盖了,那么你就无法恢复出db.hezi.insert({id: 100001})这条数据,因为这条数据
是在你备份完成后插入的数据,所以你需要立刻把oplog.rs集合给dump出来以便于进行时
间点恢复,
所以分两种情况具体如下:
情况一:
你备份开始的时间点A 到 你误删除的时间点C 这段时间的oplog.rs的数据没有被覆盖
那么就肯定能恢复出所有的数据!直接用你后来备份的oplog.rs替换你之前全备份的产生的
oplog.bson文件!
情况二:(分成两种情况)
如果你备份开始的时间点A 到 你误删除的时间点C 这段时间的oplog.rs的数据被覆盖了,
那么你就只能先恢复你的全备,然后再从oplog.rs里面尽可能找到更多的关于这个集合的
操作,然后应用,能不能全部恢复出数据,就看运气了,这里又有两种情况:
情况1:备份结束B到误删除C 这段时间内的oplog.rs没有被覆盖,那么就可以恢复出所有的数据
情况2:备份结束B到误删除C 这段时间内的oplog.rs被覆盖,那么就只能期待关于这个集合的操作
的oplog没有被覆盖,这样才能恢复出所有的数据!
怎么去分辨到底有没有被覆盖呢?
首先在你备份的机器上看,可以看出oplogs的开始和结束时间,当然这不一定准确,
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)
最好还是从你单独备份集合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的结束时间
[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}}
同理再去查看全备份的产生的oplog.bson中的开始时间和结束时间!就可以判断出有没有被覆盖了!
情况1:
1)dump出集合oplog.rs的数据
[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集合的开始时间, 当你删除某个集合的时候,她在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)需要把 前面备份的oplog.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是你前面单独备份的oplog.rs, 而oplog.bson是你全备份中带参数 --oplog产生的文件;
4)在另一个空闲实例上恢复出之前的全备份:
先把备份从21.114copy到21.115特定的目录中:
scp -r backup/ mongod@10.9.21.115:/data/mongodb/backup/
然后进行恢复:
[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将会
重放到这个时间点以前,即正好避开了第一条删除语句及其后面的操作,数据库停留在灾难
前状态
验证确实恢复出来了:
MongoDB Enterprise > db.hezi.count()
100000
5)把恢复出来的数据在恢复到生产上去:
在21.115上备份:
mongodump -h 10.9.21.115 -u liuwenhe -p liuwenhe -d liuwenhe -dliuwenhe -c hezi --authenticationDatabase admin -o /data/mongodb/
在21.115上直接恢复,前提网络通,如果不通的话,先把备份文件copy到生产上。然后恢复:
[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中的第一种情况:
备份结束B到误删除C 这段时间内的oplog.rs没有被覆盖,那么就可以恢复出所有的数据,具体
恢复过程如下:
1.恢复一致性全备份:
[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.然后再继续增量恢复oplog,从备份的oplog.rs文件中找到删除hezi这个集合的时间点,因为opglog
的幂等性,可以重复执行也不会造成数据不一致,所以没必要在导出oplog.rs的时候选择增量导出;
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中的第二种情况:
备份结束B到误删除C 这段时间内的oplog.rs被覆盖,那么就只能期待关于这个集合的操作
的oplog没有被覆盖,这样才能恢复出所有的数据!坦白讲这种情况下,没法确认到底关于
这个集合的操作的oplogs有没有被覆盖,只能先恢复看了,过程同情况2中的第一种情况;
综上所述:
mongodb的时间点恢复的过程类似于mysql借助binlog的过程,但是区别是
mysql需要找到具体的 gtid点,增量恢复,但是mongodb的oplog是可以多次执行,这样就使得
mongodb 借助oprlog的时候操作简单些;
看完上述内容是否对您有帮助呢?如果还想对相关知识有进一步的了解或阅读更多相关文章,请关注创新互联-成都网站建设公司行业资讯频道,感谢您对创新互联的支持。
新闻标题:mongodb中怎么利用oplog恢复时间点-创新互联
标题路径:http://myzitong.com/article/goosi.html