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

Question

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

是的，我可以自己编写脚本，但我认为肯定有人已经这样做了。

我注意到在服务器出现故障后，Mongodb 处于无法通过/etc/init.d/mongod 脚本重新启动的状态。显然，需要删除锁定文件，并且需要使用 --repair 选项启动它并首先更正 --dbpath，然后才能成功重新启动。在某些情况下，还需要将 db 文件的所有权更改为运行 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+ 中默认开启，默认情况下会执行“修复”。

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

Any opinions on why it might be a bad idea to try to automatically repair mongodb?

自动修复 MongoDB 的第一大问题只是其中之一。

如果你有200GB的数据库，系统在修复时需要做以下操作:

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

如果您查看我的笔记，就会发现执行维修时需要大量驱动器抖动。

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

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