生产中重新启动/自动修复Mongodb

Question

我想要实现的是拥有一个/etc/init.d脚本,它可以更可靠地启动Mongodb,即使它很难用 - 它应该在系统处于锁定状态时尝试自动修复.

是的,我可以自己编写脚本,但我认为那里的人肯定已经这样做了.

我注意到在服务器出现故障后,Mongodb处于不通过/etc/init.d/mongod脚本重启的状态.显然需要删除锁定文件,并且需要首先使用--repair选项启动并更正--dbpath,然后才能成功重新启动.在某些情况下,还需要将db-files的所有权更改为运行mongodb的用户.另外一个问题是标准的/etc/init.d/mongod脚本在这种情况下不会报告失败,而是以"OK"状态快速且错误地返回,报告Mongod已启动,尽管事实并非如此.

$ 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

Answer 1

所以首先要提到的是日记.日记实际上被称为"快速修复".默认情况下,日记功能在2.0+中启用,默认情况下它将执行"修复".

因此,如果您的磁盘可以处理额外的日志写入吞吐量,这可能会解决您的问题.

有关为什么试图自动修复mongodb可能是个坏主意的任何意见？

自动修复MongoDB的首要问题只是时间问题之一.

如果您有200GB的数据库,系统在修复时需要执行以下操作:

1. 分配~200GB的文件(你有驱动器空间吗？)
2. 将现有文件中的所有数据读入内存(200GB read)
3. 检查每个文档的有效性并将其写回新文件(200GB write)
4. 重新创建所有索引(200GB reads + large number of writes)
5. 将所有内容刷新到磁盘

如果你看看我的笔记,那就是大量的驱动器在进行维修时会发生颠簸.

但是大多数生产安装都在运行副本集.在这种情况下,您可以从备份中恢复,而不是修复.从备份恢复只会将数据写入一次,这是您应该已经存在的过程.

尽管init.d脚本返回OK,但系统监控应告诉您数据库未启动.