我想要实现的是有一个/etc/init.d脚本，它可以更可靠地启动Mongodb，即使遇到困难 – 它应该在系统处于locking状态时尝试进行自动修复。
是的，我可以自己编写这个脚本，但是我认为那里有人肯定已经这样做了。
我注意到在服务器出现故障之后，Mongodb处于不通过/etc/init.d/mongod脚本重新启动的状态。 显然，锁文件需要被删除，并且需要使用–repair选项来启动，并且必须先修改–dbpath才能成功重启。 在某些情况下，还需要将db文件的所有权更改为运行mongodb的用户。 另一个问题是，标准的/etc/init.d/mongod脚本在这种情况下不报告失败，而是以“OK”的状态返回快乐和不正确的状态，报告说Mongod已经启动了，尽pipe事实并非如此。
$ sudo /etc/init.d/mongod start Starting mongod: forked process: 9220 all output going to: /data/mongo/log/mongod.log [ OK ] $ sudo /etc/init.d/mongod status mongod dead but subsys locked 操作系统是CentOS或Fedora。
有没有人修改/etc/init.d脚本或指向这些脚本的指针，在这种情况下会自动尝试修复？ 还是有另一个工具，作为Mongod的看门狗？
任何意见，为什么它可能是一个坏主意，试图自动修复mongodb？
$ sudo /etc/init.d/mongod status mongod dead but subsys locked $ sudo ls -l /var/lib/mongo/mongod.lock -rw-r--r--. 1 mongod mongod 5 Nov 19 11:52 /var/lib/mongo/mongod.lock $ sudo tail -50 /data/mongo/log/mongod.log ************** old lock file: /data/mongo/db/mongod.lock. probably means unclean shutdown recommend removing file and running --repair see: http://dochub.mongodb.org/core/repair for more information ************* Sat Nov 19 11:55:44 exception in initAndListen std::exception: old lock file, terminating Sat Nov 19 11:55:44 dbexit: Sat Nov 19 11:55:44 shutdown: going to close listening sockets... Sat Nov 19 11:55:44 shutdown: going to flush oplog... Sat Nov 19 11:55:44 shutdown: going to close sockets... Sat Nov 19 11:55:44 shutdown: waiting for fs preallocator... Sat Nov 19 11:55:44 shutdown: closing all files... Sat Nov 19 11:55:44 closeAllFiles() finished Sat Nov 19 11:55:44 dbexit: really exiting now
所以首先要提到的是日志。 日记有效地被称为“快速修复”。 日记默认情况下在2.0以上，它将默认执行“修复”。
所以如果你的磁盘可以处理额外的日志记录吞吐量，这可能会解决你的问题。
任何意见，为什么它可能是一个坏主意，试图自动修复mongodb？
自动修复MongoDB的头号问题只是时间问题之一。
如果您有一个200GB的数据库，则系统在修复时需要执行以下操作：
200GB read入内存（ 200GB read ） 200GB write ） 200GB reads + large number of writes ） 如果你看我的笔记，这是一个严重的驱动器进行修复。
但大多数生产安装正在运行副本集。 在这种情况下，您可以从备份中恢复而不是修复。 从备份恢复只写一次数据，这是一个你应该已经拥有的过程。
尽管init.d脚本返回OK ，您的系统监视应该会告诉您该数据库没有启动。
只是想指出，日记在32位版本中工作。 但是，它在32位默认情况下不是。