记一次断电引起的mongodb彻底奔溃【转载】

周末四台mongodb主机同时断电，起来后shard中两个分片的主副本全部损坏。瞬间我xxxxxxxxx，此处省略300字。

接下来开始我的漫长修复之旅。先说明下，我的存储数据有11亿条，20T。

一、先修复shard0004的第一个复制集吧，先尝试用了官方的mongod repair.跑了2天，还是奔溃了，报其中几个collection的wt文件找不到。马上百度、google，居然都没有人提到这个问题。。。草泥马。。。

最后还是去下载了wt，尝试看看有啥办法修复，这其中历经艰辛，你们也不想了解了，直接说解决办法。

1.必须下载编译wt，这个自己到wiretiger官网去下。

2.在本地新建一个备份目录bak，吧dbpath下的所有wiretiger等文件都靠过来，还有 sizeStorer.wt。

3.在把第二步做的备份目录，再拷贝一份bak2，这步非常非常关键。否则会有问题。

4.在bak2目录下，执行./wt -v -h ./bak2 -C "extensions=[./ext/compressors/snappy/.libs/libwiredtiger_snappy.so]" list|grep 丢失的文件名（不要含wt）

会有三个。

然后分别执行（drop掉三个）：

./wt -v -h ./bak2 -C "extensions=[./ext/compressors/snappy/.libs/libwiredtiger_snappy.so]" drop file:local/index-3-2981754152560542274.wt

然后再执行：（只执行一次）

./wt -v -h ./bak2 -C "extensions=[./ext/compressors/snappy/.libs/libwiredtiger_snappy.so]" create local/index-3-2981754152560542274
5.然后吧生成的wt文件考回bak目录下去。
6.在bak目录下执行：
./wt -v -h ./bak -C "extensions=[./ext/compressors/snappy/.libs/libwiredtiger_snappy.so]" -R salvagelocal/index-3-2981754152560542274
7.把bak目录下的所有wiretiger文件和新生成的wt文件都考回正式库，然后就可以启动啦。

以上是关于wt文件丢失的处理办法。

二、然后再说下如果是报wt文件的checksum不对的处理办法。这个处理比较简单，网络上也有。
还是用wt来处理：
1.新建一个bak目录，把上面第二步说的都拷过去（这里其实不建bak也可以的，对正式库没有影响。）
2.在bak目录执行，发现和上面一样啦
./wt -v -h ./bak -C "extensions=[./ext/compressors/snappy/.libs/libwiredtiger_snappy.so]" -R salvagelocal/index-3-2981754152560542274
3.哦耶，还是把上面第7步说的东西考回正式库，就可以起来啦。

三、还记得上面用过repair吗？我去，他导致local下的index文件报错。这个还没有办法用wt。很简单，继续用官方的repair来做一遍就好了。

四、终于完成一个副本集的修复啦，oh my god。

五、还有一个shard的要修复啊。这个更奔溃，wiretiger自己的wt损坏了。这个我很负责的告诉你，截止20170726，没有办法修复。我是把这些文件打包发给官方去修复的。官方会响应，但是我可是等不了他了。咳。。

所以最后最后最后，我还是重建了另一个shard，当做所有shard数据丢失。

再说下，停电重启后，dbpath是无法再mount上去了。说结构需要清理。xfs_repair又说有log 要replay。最后我没办法还能加-L参数，摧毁了replay log。郁闷不。（官网就是让我们去mount的，但是我查网络上貌似都做不到。）

杨建飘雪 最后发布于2017-07-26 09:41:21
https://blog.csdn.net/zhaow7/article/details/76104476