背景：
我在一台移动教练机上安装了一些AIO应用程序机器（运行带有rails + mongodb + chromium的ubuntu）来显示信息，偶尔用户可能会把某些数据的chuck改成mongodb。
现在，机器的电源是恒定的，主驾驶员随时可以关机。 机器有2个分区，第一个是aufs for /，另外一个是ext4 for mongodb / data目录。 但在断电的瞬间，没有数据input到数据库。
问题：
每次由于断电（每几个小时）机器重新启动，mongodb将在其目录中保留一个mongod.lock文件。 在/etc/rd.local中我试图删除每个启动的locking文件，但它有时仍然拒绝启动。 这导致我的应用程序启动失败。
根据官方文档： http ： //www.mongodb.org/display/DOCS/Durability+and+Repair ，我仍然有一些无法启动的场合。
在上述的常规电源故障情况下运行mongodb的最佳做法是什么？ 没有投入额外的硬件。
所有的mongod.lock文件告诉你，数据库有一个不干净的closures，即没有被pipe理员等停止。
当它自己运行--repair操作时，mongod将尝试读取现有文件，写入新文件，然后交换它们。 一旦完成，它应该删除mongod.lock文件，并启用您启动数据库。
如果与--repairpath参数一起使用，则修复的--repairpath将被放置在指定的修复path中，并且locking文件可能不会被删除，因为原始数据文件尚未修复，而新的文件已被写入修复的数据和指定的path。
使用--repairpath可能的stream程：
服务启动，日志消息通知您locking问题，退出。
mongod --dbpath=/data/db
你运行一个类似如下的修复命令：
mongod --dbpath=/data/db --repair --repairpath=/data/db2
并等待它完成。
一旦完成，从修复的文件path启动mongod：
mongod --dbpath=/data/db2
一旦确认工作，你可以删除/data/db目录，如果你的愿望。
所有这些都可以通过不使用–repairpath选项来replace/data/db/的文件来消除。
关于恢复，请看日志 – 这会创build一个操作日志，每100ms刷新一次持久磁盘，当mongod启动并检测到未应用的日志文件并应用它们时，删除locking文件并启动服务器。
首先，请阅读 您链接到的祝福文档：
mongod.lock
不要删除mongod.lock文件。 如果mongod无法启动，请使用上述方法之一来纠正这种情况。删除locking文件将允许数据库在其数据可能损坏时启动。 一般来说，您不应该强制数据库以可能损坏的数据开始。 在紧急情况下，您可能需要删除locking文件，以便将任何可以从服务器上取下的数据提取出来。 如果您曾经手动删除locking文件并启动服务器备份，则不应将该服务器视为“健康”。
按照链接的祝福文档中概述的步骤在电源故障后恢复。
MongoDB并不是devise成在一个将被无情地踢在头上的环境中运行的 – 如果你需要这种耐用性，你需要一个专门用于两阶段提交的数据库和刷新到磁盘的写入。