使用MONGODB 集群的OPLOG 日志进行数据恢复

原创 2015年07月07日 11:57:42

(以下方法只能恢复部分数据,因为OPLOG 表并没有保存所有的同步日志,是有大小限制的)




因为oplog 表(collection 后面为了习惯,就叫表了)没有索引,而我却要选择我需要恢复的某个表的数据。
所以先把各个分片中的oplog表分别导出到另外一台服务器进行处理:

1.备份出来:
./mongodump --port 28011 -d local -c oplog.rs  -o  /opt/backup/0706local/

2.恢复到另外一台单节点MONGODB服务器

mongorestore --port 28011 -d temp_local -c shard1_oplog  --dir /opt/backup/0706local/local/oplog.rs.bson

......
mongorestore --port 28012 -d temp_local -c shard4_oplog  --dir /opt/backup/0706local/local/oplog.rs.bson

有多少个分片,就有多少个新建立的表。

3.建立索引,以方便查询数据:
> db.shard4_oplog.createIndex({ns:1,op:1})
{
    "createdCollectionAutomatically" : false,
    "numIndexesBefore" : 0,
    "numIndexesAfter" : 1,
    "ok" : 1
}

4.本来想先把没用的数据删除的,但因为oplog原来是个capped 表,无法删除数据,只好做罢,就这样处理吧。

> db.shard4_oplog.remove({ns:"ds.tb_monitor",op:{$ne:'i'}})
WriteResult({
    "nRemoved" : 0,
    "writeError" : {
        "code" : 20,
        "errmsg" : "cannot remove from a capped collection: oplog.shard4_oplog"
    }
})


5.编写代码,对每行数据查询到后,添加到一个新的表:

关于:forEach:

Step 2: Create backup of 2.6 admin.system.users collection. Copy all documents in the
admin.system.users(page 286) collection to theadmin.system.new_userscollection:
db.getSiblingDB("admin").system.users.find().forEach( function(userDoc) {
status = db.getSiblingDB("admin").system.new_users.save( userDoc );
if (status.hasWriteError()) {
print(status.writeError);
}
}
);

使用类似方法,写了一个把日志数据保存到另外一个表的功能:
(把表名为要恢复的表名,操作类型为'i'---新数据插入 的数据取出,保存到另外一个新表)

db.shard3_oplog.find({ns:"ds.tb_monitor",op:'i'}).forEach(function(res_data){
obj_doc = res_data["o"]; #取出oplog中插入的JSON对象
status = db.tb_monitor.save( obj_doc ); #保存到新表中。
if (status.hasWriteError()) {
print(status.writeError);
}
}
)


6.再把这个新建立的表,导出,再恢复到集群中为一个新表,再使用5方法,保存到源表中。

./mongodump  -d local -c shard1_oplog  -o  /opt/backup/0706local/

mongorestore --port 28000 -d temp_local -c new_collection  --dir /opt/backup/0706local/local/shard1_oplog.bson


db.new_collection.find().forEach(function(res_data){
status = db.tb_monitor.save( res_data );
if (status.hasWriteError()) {
print(status.writeError);
}
}
)

版权声明:本文为博主原创文章,未经博主允许不得转载。

Mongodb Replica sets 重新同步报错

$err: "getMore executor error: CappedPositionLost CollectionScan died due to position in capped coll...
  • dazuiba008
  • dazuiba008
  • 2016年08月09日 16:56
  • 391

mongo主从

参数说明: mongod为mongoDB的server程序,启动参数使用的主要有如下几个 --fork fork出一个server端的daemon进程 --port server监听...
  • Steven_liwen
  • Steven_liwen
  • 2016年06月29日 10:24
  • 490

MongoDB 分片集群故障RECOVERING 处理纪实

1、问题描述,备库故障RECOVERING运营同事说查询mongodb备库数据,没有最新的记录,估计是复制延时了,或者是故障了,赶紧上去查看状态rs.status(),看到备库处于RECOVERING...
  • mchdba
  • mchdba
  • 2017年03月12日 18:28
  • 3918

MongoDB误操作恢复测试

前序: 由于无论在什么架构下,都会不可避免的出现人为误操作的事故出现,本文就对可能出现的误操作问题的解决办法进行测试,这些都是本人想到的解决办法并加以测试实验 架构:Replica set (1Pri...
  • jianlong727
  • jianlong727
  • 2016年12月06日 12:08
  • 3774

Mongo主从同步local.oplog.$main oplog is empty

Mongo主从同步,简单的master-slave以及单机器同步副本集群时。mongo提示 一直无法同步,检查local库oplog。发现数据库信息同步为空。数据有4个G。(废话太多) 关闭mon...
  • x369201170
  • x369201170
  • 2015年04月27日 18:33
  • 1876

mongodb副本集备份时需要oplog吗?

作为一个合格的dba((⊙o⊙)…我是菜鸟),备份应该是重中之重,就像‘兵马未动粮草先行’,完善的备份可以救你一命啊,切记,切记!...
  • xdstuhq
  • xdstuhq
  • 2016年11月02日 10:31
  • 545

MongoDB3.4 版本新节点同步的一点惊喜

一个日志库数据量过大,以前3.2 版本的MongoDB oplogsize=50G  也没法初始化新节点。 在把版本升级到3.4,磁盘选择高效云盘后。再做新节点初始化数据同步。 时间已从以前的3天...
  • miyatang
  • miyatang
  • 2017年02月23日 10:02
  • 1471

修改mongodb oplog size

修改mongodb oplog size oplog简介: oplog:operations log的简写,存储在一个特殊的数据库中(local),oplog就存储在其中的oplog.$main集...
  • huwei2003
  • huwei2003
  • 2015年01月30日 15:28
  • 9155

mongoDB的复制集2----同步机制(工作原理,oplog详解,初始化同步的过程

一、复制集是怎么工作的 1-1.复制集工作原理     Mongodb复制集由一组Mongod实例(进程)组成,包含一个Primary节点和多个Secondary节点,Mongodb Driver(客...
  • oChangWen
  • oChangWen
  • 2016年08月29日 20:46
  • 1922

搭建MongoDB副本集还需要做些什么(Oplog调整)

一边搭建一边理解MongoDB副本集(Oplog)作者:链上研发-175405 时间:2017-01-06oplog(operation log) 是一个特殊的有界集合,它维护了所有保存在数据库中...
  • fang_sh_lianjia
  • fang_sh_lianjia
  • 2017年01月11日 22:40
  • 223
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:使用MONGODB 集群的OPLOG 日志进行数据恢复
举报原因:
原因补充:

(最多只允许输入30个字)