mongod自带了两种修复工具
mongod自带了两种修复工具，一种是mongod内置的，另一种是mongodump内置的。mongodump的修复更加接近底层，可能会找到更多的数据，但耗时要更长（而另一种自带的修复方式也不见得很快）。另外，如使用mongodump的修复，在准备再次启动前，依然需要恢复数据的操作。
因此，应根据愿意在数据恢复中消耗的时间长短来进行决定。
要使用mongod内置的修复工具，需附带--repair选项运行mongod:
$ mongod --dbpath /path/to/corrupt/data --repair
进行修复时，MongoDB不会开启27017端口的监听，但我们可通过査看日志（log) 的方式得知它正在做什么。注意，修复过程会对数据进行一份完整的复制，所以如有80 GB的数据，则需80 GB的空闲磁盘空间。为尽量解决这一问题，修复工具提供了--repairpath选项。这一选项允许在主磁盘空间不足时挂载一个“紧急驱动器”，并使用它来进行修复操作。--repairpath选项的用法如下：
$ mongod --dbpath /path/to/corrupt/data \
> --repair --repairpath /media/external-hd/data/db
如果修复过程被强行终止，或者出现故障（如磁盘空间不足），至少不会使情况变得更糟。修复工具将所有的输出都写入新的文件中，不会对原有文件进行修改。因此原始数据文件不会比开始修复时变得更糟。
另一个选择是使用mongodump的--repair选项，就像这样：
$ mongodump --repair
这些选择都不是特别好，但它们应该可以让mongod重新运行在一个干净的数据集上。
在硬件或文件系统出现故障等情况下，MongoDB无法保证操作的持久性。尤其是在硬盘发生损坏的情况下，MongoDB根本无法保证数据安全。
另外，不同的硬件和软件对于持久性的保障可能有所不同。例如，一些破旧的硬盘会在写入操作还在列队中等待之际，便报告称写入成功。MongoDB无法防止这一层次的误报，如果此时系统崩溃，数据就可能会发生丢失。
基本上，MongoDB的安全性与其所基于的系统相同，MongoDB无法避免硬件或文件系统导致的数据损坏。可使用副本应对系统问题。如果一台机器发生了故障，还有另一台在正常工作
docker 环境下的修复
docker mongo 一直重启,无法进入terminal ,可以新容器挂载本地的数据 ,覆盖掉原来的entrypoint入口命令
docker run -it --rm -v `pwd`/data:/data/db --entrypoint /bin/bash mongo
运行修复命令
mongod --repair --dbpath /path/to/data/db