MongoDB误删表恢复

一、场景描述

公司某工程师执行db.giveget_card.drop(),误将线上表删除。

幸好每天都有做备份,这个时候就体现了备份的重要性了,哈哈哈。。。

二、模拟故障过程:

备份数据大小:

rs_test01:PRIMARY> use ycsb
switched to db ycsb
rs_test01:PRIMARY> db.giveget_card.count();
3173391

删除之前,此表有更新。

rs_test01:PRIMARY> db.giveget_card.insert({id:1});
WriteResult({ "nInserted" : 1 })
rs_test01:PRIMARY> db.giveget_card.insert({id:2});
WriteResult({ "nInserted" : 1 })
rs_test01:PRIMARY> db.giveget_card.insert({id:3});
WriteResult({ "nInserted" : 1 })
rs_test01:PRIMARY> db.giveget_card.insert({id:4});
WriteResult({ "nInserted" : 1 })

其他表也有更新操作。

rs_test01:PRIMARY> db.tab.find();
{ "_id" : ObjectId("59354ba202d9a99ab2f879c6"), "name" : "a" }
{ "_id" : ObjectId("59354ba602d9a99ab2f879c7"), "name" : "b" }
{ "_id" : ObjectId("59354ba802d9a99ab2f879c8"), "name" : "c" }
{ "_id" : ObjectId("59354baa02d9a99ab2f879c9"), "name" : "d" }

删除操作之后,此表和其他表都有更新。

rs_test01:PRIMARY> db.giveget_card.find();
{ "_id" : ObjectId("59354c28d905432aeaccd53c"), "id" : 5 }
{ "_id" : ObjectId("59354c2bd905432aeaccd53d"), "id" : 6 }
rs_test01:PRIMARY> db.tab.find();
{ "_id" : ObjectId("59354ba202d9a99ab2f879c6"), "name" : "a" }
{ "_id" : ObjectId("59354ba602d9a99ab2f879c7"), "name" : "b" }
{ "_id" : ObjectId("59354ba802d9a99ab2f879c8"), "name" : "c" }
{ "_id" : ObjectId("59354baa02d9a99ab2f879c9"), "name" : "d" }
{ "_id" : ObjectId("59354ccfd905432aeaccd542"), "name" : "e" }
{ "_id" : ObjectId("59354cd2d905432aeaccd543"), "name" : "f" }

三、恢复步骤

1、将备份中tab表的giveget_card.bson及giveget_card.metadata.json文件拷贝到/tmp/restore/ycsb目录(自建目录),ycsb 为库名。

# cp /data/backup/rs07/ycsb/giveget_card.* /tmp/restore/ycsb

2、将备份时间之后,误删操作之前的oplog导出,用于恢复表

# mongodump --port 2203 -d local -c oplog.rs -q ‘{"ts" : {$gte : Timestamp(1496664480, 10430), $lte : Timestamp(1496665113, 10430)}}‘ -o /tmp/oplog

--时间戳 是使用转换工具转换之后的结果。

3、使用bsondump查看oplog日志,找到drop操作的时间戳1496665069

# bsondump /tmp/oplog/local/oplog.rs.bson 
{"ts":{"$timestamp":{"t":1496664760,"i":1}},"t":{"$numberLong":"12"},"h":{"$numberLong":"7079172056815894727"},"v":2,"op":"i","ns":"ycsb.giveget_card","o":{"_id":{"$oid":"59354ab8c5308d8c7a9da8b5"},"id":1.0}}
{"ts":{"$timestamp":{"t":1496664762,"i":1}},"t":{"$numberLong":"12"},"h":{"$numberLong":"-1797107728294067016"},"v":2,"op":"i","ns":"ycsb.giveget_card","o":{"_id":{"$oid":"59354abac5308d8c7a9da8b6"},"id":2.0}}
{"ts":{"$timestamp":{"t":1496664765,"i":1}},"t":{"$numberLong":"12"},"h":{"$numberLong":"8604646791509150392"},"v":2,"op":"i","ns":"ycsb.giveget_card","o":{"_id":{"$oid":"59354abdc5308d8c7a9da8b7"},"id":3.0}}
{"ts":{"$timestamp":{"t":1496664768,"i":1}},"t":{"$numberLong":"12"},"h":{"$numberLong":"9018614066505371436"},"v":2,"op":"i","ns":"ycsb.giveget_card","o":{"_id":{"$oid":"59354ac0c5308d8c7a9da8b8"},"id":4.0}}
{"ts":{"$timestamp":{"t":1496664994,"i":1}},"t":{"$numberLong":"12"},"h":{"$numberLong":"-4471524661347063602"},"v":2,"op":"c","ns":"ycsb.$cmd","o":{"create":"tab"}}
{"ts":{"$timestamp":{"t":1496664994,"i":2}},"t":{"$numberLong":"12"},"h":{"$numberLong":"-4215905958456607246"},"v":2,"op":"i","ns":"ycsb.tab","o":{"_id":{"$oid":"59354ba202d9a99ab2f879c6"},"name":"a"}}
{"ts":{"$timestamp":{"t":1496664998,"i":1}},"t":{"$numberLong":"12"},"h":{"$numberLong":"6170506962401844481"},"v":2,"op":"i","ns":"ycsb.tab","o":{"_id":{"$oid":"59354ba602d9a99ab2f879c7"},"name":"b"}}
{"ts":{"$timestamp":{"t":1496665000,"i":1}},"t":{"$numberLong":"12"},"h":{"$numberLong":"-8071456063660489895"},"v":2,"op":"i","ns":"ycsb.tab","o":{"_id":{"$oid":"59354ba802d9a99ab2f879c8"},"name":"c"}}
{"ts":{"$timestamp":{"t":1496665002,"i":1}},"t":{"$numberLong":"12"},"h":{"$numberLong":"4387884836668659146"},"v":2,"op":"i","ns":"ycsb.tab","o":{"_id":{"$oid":"59354baa02d9a99ab2f879c9"},"name":"d"}}
{"ts":{"$timestamp":{"t":1496665069,"i":1}},"t":{"$numberLong":"12"},"h":{"$numberLong":"-6913449254950935781"},"v":2,"op":"c","ns":"ycsb.$cmd","o":{"drop":"giveget_card"}}
2017-06-05T20:27:25.552+0800	10 objects found

4、将oplog的bson文件拷贝到相应目录下

# cp /tmp/oplog/local/oplog.rs.bson /tmp/restore/oplog.bson

此时恢复的目录结构:

# pwd
/tmp/restore
# ls
oplog.bson  ycsb

5、至此,所有的准备操作已经做完,恢复数据。

[[email protected] restore]# mongorestore --port 2203 --oplogReplay --oplogLimit=1496665069:1 /tmp/restore
2017-06-05T20:36:45.361+0800	building a list of dbs and collections to restore from /tmp/restore dir
2017-06-05T20:36:45.364+0800	reading metadata for ycsb.giveget_card from /tmp/restore/ycsb/giveget_card.metadata.json
2017-06-05T20:36:45.364+0800	restoring ycsb.giveget_card from /tmp/restore/ycsb/giveget_card.bson
2017-06-05T20:36:48.362+0800	[........................]  ycsb.giveget_card  15.4MB/475MB  (3.2%)
2017-06-05T20:36:51.362+0800	[#.......................]  ycsb.giveget_card  31.1MB/475MB  (6.6%)
2017-06-05T20:36:54.362+0800	[##......................]  ycsb.giveget_card  46.6MB/475MB  (9.8%)
2017-06-05T20:36:57.362+0800	[###.....................]  ycsb.giveget_card  62.1MB/475MB  (13.1%)
2017-06-05T20:37:00.362+0800	[###.....................]  ycsb.giveget_card  76.4MB/475MB  (16.1%)
2017-06-05T20:37:03.362+0800	[####....................]  ycsb.giveget_card  90.7MB/475MB  (19.1%)
2017-06-05T20:37:06.362+0800	[#####...................]  ycsb.giveget_card  105MB/475MB  (22.0%)
2017-06-05T20:37:09.362+0800	[######..................]  ycsb.giveget_card  120MB/475MB  (25.2%)
2017-06-05T20:37:12.362+0800	[######..................]  ycsb.giveget_card  133MB/475MB  (28.0%)
2017-06-05T20:37:15.362+0800	[#######.................]  ycsb.giveget_card  146MB/475MB  (30.8%)
2017-06-05T20:37:18.363+0800	[########................]  ycsb.giveget_card  163MB/475MB  (34.3%)
2017-06-05T20:37:21.362+0800	[########................]  ycsb.giveget_card  178MB/475MB  (37.4%)
2017-06-05T20:37:24.362+0800	[#########...............]  ycsb.giveget_card  196MB/475MB  (41.3%)
2017-06-05T20:37:27.362+0800	[##########..............]  ycsb.giveget_card  214MB/475MB  (45.0%)
2017-06-05T20:37:30.362+0800	[###########.............]  ycsb.giveget_card  231MB/475MB  (48.6%)
2017-06-05T20:37:33.362+0800	[############............]  ycsb.giveget_card  245MB/475MB  (51.5%)
2017-06-05T20:37:36.362+0800	[#############...........]  ycsb.giveget_card  261MB/475MB  (54.8%)
2017-06-05T20:37:39.362+0800	[##############..........]  ycsb.giveget_card  279MB/475MB  (58.7%)
2017-06-05T20:37:42.362+0800	[###############.........]  ycsb.giveget_card  297MB/475MB  (62.5%)
2017-06-05T20:37:45.362+0800	[###############.........]  ycsb.giveget_card  312MB/475MB  (65.8%)
2017-06-05T20:37:48.362+0800	[################........]  ycsb.giveget_card  328MB/475MB  (69.0%)
2017-06-05T20:37:51.362+0800	[#################.......]  ycsb.giveget_card  341MB/475MB  (71.8%)
2017-06-05T20:37:54.362+0800	[#################.......]  ycsb.giveget_card  356MB/475MB  (74.9%)
2017-06-05T20:37:57.362+0800	[##################......]  ycsb.giveget_card  373MB/475MB  (78.5%)
2017-06-05T20:38:00.362+0800	[###################.....]  ycsb.giveget_card  388MB/475MB  (81.7%)
2017-06-05T20:38:03.362+0800	[####################....]  ycsb.giveget_card  405MB/475MB  (85.2%)
2017-06-05T20:38:06.362+0800	[#####################...]  ycsb.giveget_card  419MB/475MB  (88.2%)
2017-06-05T20:38:09.362+0800	[#####################...]  ycsb.giveget_card  434MB/475MB  (91.4%)
2017-06-05T20:38:12.362+0800	[######################..]  ycsb.giveget_card  442MB/475MB  (93.1%)
2017-06-05T20:38:15.362+0800	[#######################.]  ycsb.giveget_card  459MB/475MB  (96.6%)
2017-06-05T20:38:18.362+0800	[#######################.]  ycsb.giveget_card  475MB/475MB  (99.9%)
2017-06-05T20:38:18.427+0800	[########################]  ycsb.giveget_card  475MB/475MB  (100.0%)
2017-06-05T20:38:18.427+0800	restoring indexes for collection ycsb.giveget_card from metadata
2017-06-05T20:38:44.680+0800	finished restoring ycsb.giveget_card (3173391 documents)
2017-06-05T20:38:44.680+0800	replaying oplog
2017-06-05T20:38:44.739+0800	done

6、查看恢复的结果

rs_test01:PRIMARY> db.giveget_card.find({id : {$gte : 1 }});
{ "_id" : ObjectId("59354cb9d905432aeaccd540"), "id" : 5 }
{ "_id" : ObjectId("59354cc0d905432aeaccd541"), "id" : 6 }
{ "_id" : ObjectId("59354ab8c5308d8c7a9da8b5"), "id" : 1 }
{ "_id" : ObjectId("59354abac5308d8c7a9da8b6"), "id" : 2 }
{ "_id" : ObjectId("59354abdc5308d8c7a9da8b7"), "id" : 3 }
{ "_id" : ObjectId("59354ac0c5308d8c7a9da8b8"), "id" : 4 }

数据内容相同,但存储顺序与之前数据的存储顺序不同了。

rs_test01:PRIMARY> db.giveget_card.count();
3173397

结果count=备份表数据3173391+之后的更新数据6 。

7、因为dump出来的oplog也包含了其他表的操作。查看恢复过程中有没有对其他表产生影响。

rs_test01:PRIMARY> db.tab.find();
{ "_id" : ObjectId("59354ba202d9a99ab2f879c6"), "name" : "a" }
{ "_id" : ObjectId("59354ba602d9a99ab2f879c7"), "name" : "b" }
{ "_id" : ObjectId("59354ba802d9a99ab2f879c8"), "name" : "c" }
{ "_id" : ObjectId("59354baa02d9a99ab2f879c9"), "name" : "d" }
{ "_id" : ObjectId("59354ccfd905432aeaccd542"), "name" : "e" }
{ "_id" : ObjectId("59354cd2d905432aeaccd543"), "name" : "f" }

--查看tab表的数据跟原表数据相同,没有什么影响,说明其他表的日志在空跑。

以上就是备份结合oplog的恢复操作。

备份很重要!!! 备份很重要!!! 备份很重要!!!

重要的事情讲三遍~~~

时间: 2025-01-18 15:14:14

MongoDB误删表恢复的相关文章

SQL Server误删表恢复

SQL Server 完全恢复模式 下恢复误删除的表,进行 精准 恢复 1.  找出被删除的表名(无schema,能找到schema的分享下).object_id.表所在数据库.删除人.删除时间等 declare @database_name varchar(200),@type varchar(2),@pass_hours int, select @database_name='AdventureWorks2014',@pass_hours=-48 declare @file_path sql

表误删记录恢复操作

表误删记录恢复操作 最近处理了个用户误删delete table 的故障,这里做了一个简单的汇总,文章内容整理自pub 里的各位大师的精粹,我这里偷个懒直接拿来用下. 基本处理思路: 1.如果还没有提交,用rollback.(应该不大可能.) 2.如果提交时间超过5分钟以上且小于undo_retention的设置,可以使用回闪功能.具体限制和操作可以参考:http://blog.itpub.net/post/468/15464 3.如果上述两条都不满足,可以使用logminer从redo中恢复,

Oracle闪回技术之一Oracle 11g 利用FlashTable (闪回表)恢复(用delete)误删的数据

闪回表,实际上就是将表中的数据快速恢复到过去的一个时间点或者系统改变号SCN上.实现表的闪回,需要用到撤销表空间相关的UNDO信息,通过SHOW PARAMETER UNDO命令就可以了解这些信息.用户对表的数据的修改操作,都记录在撤销表空间中,这为表的闪回提供的数据恢复的基础. 修改记录被提交到undo表空间中的默认保留时间为900秒,用户可以在这900秒的时间内对表的进行闪回操作,从而将表中的数据恢复的修改前的状态. 如上图显示的默认900秒,我们通过sql来修改这个默认时间为1200: f

Oracle中Drop,Delete,Truancate表恢复

Oracle中Drop,delete,truancate表恢复 oracle中,常常会由于一些失误导致表的删除,以下是我写的一些表恢复的方法. 闪回模式得满足条件(启用闪回区和启用归档): 1.检查是否启动了flash recovery area show parameter db_recovery_file 2.检查是否启用了归档 archive log list; (一)Drop表的恢复 如果按照平时删除表的方法:(Drop table tablename;)的话.表不会立即被删除,而是存放

MongoDB数据表基本操作

MongoDB数据表基本操作 查看全部数据表 > use ChatRoom switched to db ChatRoom > show collections Account Chat system.indexes system.users 创建数据表 > db.createCollection("Account") {"ok":1} > db.createCollection("Test",{capped:true,

iOS 符号表恢复 & 逆向支付宝

推荐序 本文介绍了恢复符号表的技巧,并且利用该技巧实现了在 Xcode 中对目标程序下符号断点调试,该技巧可以显著地减少逆向分析时间.在文章的最后,作者以支付宝为例,展示出通过在 UIAlertView 的 show 方法处下断点,从而获得支付宝的调用栈的过程. 本文涉及的代码也开源在:https://github.com/tobefuturer/restore-symbol,欢迎 Star 和提 Issue.感谢作者授权发表. 作者介绍:杨君,中山大学计算机系研究生,iOS 开发者,擅长领域

MongoDB数据库备份恢复与导入导出

一.mongodump/mongorestore方式 使用场景:数据库导出指定collection,无法手工修改导出文件(二进制)允许条件:数据库原始collection导入操作前可以被删除(处理方式:插入)或者保留(处理方式:删除然后插入)导出数据格式:二进制类型,不可手工修改 1.备份数据库指定collection C:\Users\Administrator>mongodump -d webdb -c users -o e:\webdb_users_dumpconnected to: 12

GRT Recover My File误删文件恢复

在日常的电脑操作中,我们可能会由于硬盘硬件损坏.硬盘格式化导致文件的丢失,在这种情况下,推荐一款误删文件的恢复软件给大家使用. GRT Recover My File是由GRTSoft公司推出的一款数据恢复软件,能够帮助你恢复误删的照片.电影.歌曲等资源. 功能介绍:1.GRT Recover My File支持FAT12.FAT16.FAT32.NTFS文件系统:2.可以帮助你快速的恢复被误删除的文件和文件夹,即使回收站已被清空或使用SHIFT + Del键彻底删除也可以恢复:3.程序提供了易

苹果手机照片误删怎么恢复,已删除的的照片怎么恢复

苹果手机照片误删怎么恢复,已删除的的照片怎么恢复?现在的智能机里面都存储着各种各样的照片,对于这些照片有习惯的朋友会备份,这样即使误删也不担心,那么对于没有备份的用户误删了该怎么恢复呢? 手机相册中也有一个相当于回收站的功能,如果能够在其中找到需要的照片那么就可以自行的还原,如果找不到的话,还是按照小编下面的方法来进行吧. 恢复方法一:极速恢复精灵 1.在苹果手机App Store里面找到"极速恢复精灵",将其下载安装到手机上,也可以用浏览器下载. 2.之后用户打开APP,可以看到界面