使用Wiredtiger恢复MongoDB中collection-x-xxx.wt文件数据

目录

问题：

1. 环境准备

1.1 安装MongoDB

1.2 安装Wiredtiger

1.3 文件打包

2. 恢复数据

1.『打捞』出可以被恢复的部分

2. 做些必要的数据格式调整

2.1 wt --> dump

2.2 a new collection

2.3 dump --> new wt

2.3 完善一下

3 收工

MongoDB使用建议

---

问题：

固态硬盘突然换掉，系统盘数据全部丢失，安装在固态硬盘的系统Win10和软件Python、MongoDB等都没了......

好在之前安装了双系统，Ubuntu在机械硬盘，MongoBD中的数据存也放在了机械硬盘，数据文件（总共2.5G）还在，所以想办法恢复

1. 环境准备

1.1 安装MongoDB

sudo apt-get install mongodb

建立数据库文件夹

ailab@PC-CYQ:~$ sudo mkdir /data
ailab@PC-CYQ:~$ cd /data
ailab@PC-CYQ:/data$ sudo mkdir db
ailab@PC-CYQ:/data$ ll
总用量 12
drwxr-xr-x  3 root root 4096 1月  16 19:11 ./
drwxr-xr-x 25 root root 4096 1月  16 19:11 ../
drwxr-xr-x  2 root root 4096 1月  16 19:11 db/

启动MongoDB服务

ailab@PC-CYQ:/data$ sudo chmod 777 db
ailab@PC-CYQ:/data$ sudo mongod

这里说 exception in initAndListen: 29 Data directory /data/db not found., terminating

我们自己创建文件夹，并更改权限，再次测试可以使用
 

1.2 安装Wiredtiger

Wiredtiger官网：  http://source.wiredtiger.com/index.html

wget http://source.wiredtiger.com/releases/wiredtiger-3.0.0.tar.bz2
tar xvf wiredtiger-3.0.0.tar.bz2
cd wiredtiger-3.0.0

sudo yum install snappy-devel -y    #如果是ubuntu则用 sudo apt-get install libsnappy-dev build-essential

./configure --enable-snappy
make

1.3 文件打包

准备好要恢复的collection*****.wt，以及读取它必备的_mdb_catalog.wt、sizeStorer.wt、storage.bson、WiredTiger、WiredTiger.basecfg、WiredTiger.lock、WiredTiger.turtle、WiredTiger.wt。我们可以把这些文件放到一个新目录，比如本例放到dump(或者其他的，任意)文件夹下，目录结构如下：

collection-0--282010455938071573.wt			# 要恢复的collection文件
_mdb_catalog.wt
sizeStorer.wt
storage.bson
WiredTiger
WiredTiger.basecfg
WiredTiger.lock
WiredTiger.turtle
WiredTiger.wt

2. 恢复数据

切换到wiredtiger目录下：

1.『打捞』出可以被恢复的部分

./wt -v -h ../dump -C "extensions=[./ext/compressors/snappy/.libs/libwiredtiger_snappy.so]" -R salvage collection******.wt

这一步操作会读取我们指定的collection*****.wt，忽略所有无法被恢复的数据，然后把新数据覆盖回去。当然你也可以修改参数让它把salvage后的文件写到另一个地方。

运行上述命令会输出WT_SESSION.salvage 100这样的结果，后面那个数量其实就是所有能被恢复的数据。但是你现在还不能把这个直接读取到MongoDB。

2. 做些必要的数据格式调整

因为上一步产生的wt文件还没法直接用MongoDB读，所以我们接下来这几步就利用wt的dump和load工具想办法把他们导入到MongoDB。

2.1 wt --> dump

注意这一步操作指定的collection不需要写wt扩展名了

./wt -v -h ../dump -C "extensions=[./ext/compressors/snappy/.libs/libwiredtiger_snappy.so]" -R dump -f ../collection.dump collection******

这一步会把我们刚打捞出来的健康的wt文件dump到上级目录的collection.dump文件（当然这个文件叫什么名、存哪里你自己定，下一步你还能找到就行）。

还要注意的是这一步程序是没有任何状态输出的（如果你看到了估计肯定是错误提示……），如果想看到进度的话可以用shell中的ls -l等命令通过观察collection.dump文件的变化来揣测进度，以及带给你一些程序确实运行成功了的安全感。

2.2 a new collection

这一步主要是为接下来的load做准备：我们要建立一个新的数据库，然后把上一步dump的数据导入进来，然后还有几个关键而鬼畜的步骤，后面都会提到，所以这一步还是老老实实跟着做一下吧。

来，我们先启动一个新的Mongo实例，我举个栗子，可以这么做：

mongod --dbpath tmp-mongo --storageEngine wiredTiger --nojournal

然后我们要连接这个实例并创建一个新集合

mongo
> use Recovery
> db.brokedCollection.insert({test: 1})
> db.brokedCollection.remove({})
> db.brokedCollection.stats()

我们创建了一个新的叫做Recovery的数据库，并且插入移除过文档，所以这些集合的数据文件会被生成。使用stats()方法可以查看集合所对应的wt文件名称，当然了，因为我们只使用了一个集合，所以跑到tmp-mongo目录下ls一下也就知道这个collecion对应的wt文件是哪个了……为什么要知道这个？当然是下一步要用了……

2.3 dump --> new wt

接下来是见证奇迹的时刻：我们的数据很快就可以重现Mongo了！

./wt -v -h ../tmp-mongo -C "extensions=[./ext/compressors/snappy/.libs/libwiredtiger_snappy.so]" -R load -f ../collection.dump -r collection******

这一步就是把前面转出来的dump文件读入上一步生成的collection文件，所以-h指定的当然是我们上一步用的新mongo实例的路径。执行这一步的时候需要先把Mongo关上，不然mongo进程会霸占着这个wt文件不让你操作。

这个操作是有一个进度展示的table:collection-******: 356

来来来，见证一下奇迹：现在可以再用2.2里的方式启动这个Mongo实例了

mongo
> show dbs              //应该可以看到Recovery有数据了
> use Recovery
> show collections      //应该可以看到brokedCollection里有数据了
> db.brokedCollection.count()   //是0？呐尼？

看到0的那一刻估计你又开始紧张了，别急我们慢慢来，如果到这一步就能解决问题的话我们何苦要折腾出2.2.2这一步。

> db.brokedCollection.find({}, {_id: 1})

接着执行这一条能看到数据，所以我估计你会再次燃起希望，接下来我们继续，让奇迹2出现吧：

2.3 完善一下

需要注意为了防止出错执行下面的步骤要确保MongoDB版本不小于3.2（因为3.2版本才是基于WiredTiger2.7构建的）。

mongodump

mongorestore --drop

没错就是这么简单，接下来我们就可以验证奇迹了。

mongo
> show dbs
> use Recovery
> show collections
> db.brokedCollection.count()
> db.brokedCollection.find({},{_id:1})

这次都回来了吧，一切正常了吧……接下来可以restore到任何你想要restore的地方了，如何使用可自由发挥。

3 收工

收工吧，累死了。

也许你已经受到上面步骤的启发想到更多有意思的恢复方法了，然而人生苦短，适可而止……

MongoDB使用建议

对重要数据库所在机器操作前一定要提前backup一下，把万万没想到的损失降到最低；还有，除非真的不care数据的高可用性，不要随便关journal；单台机器上有多个库的话最好在配置文件中设置下directoryPerDB:true，让每个库有一个单独文件夹；有富余机器的话尽量做一下复制集……