为什么MongoDB不会自动重启？

Question

如果 MongoDB 3.6 崩溃，它似乎不会自动配置为重新启动。查看与 Ubuntu 16.04LTS 的最新 .deb 包捆绑在一起的 systemd 服务，它似乎没有配置重启：

$ sudo systemctl cat mongod
# /lib/systemd/system/mongod.service
[Unit]
Description=High-performance, schema-free document-oriented database
After=network.target
Documentation=https://docs.mongodb.org/manual

[Service]
User=mongodb
Group=mongodb
ExecStart=/usr/bin/mongod --config /etc/mongod.conf
PIDFile=/var/run/mongodb/mongod.pid
# file size
LimitFSIZE=infinity
# cpu time
LimitCPU=infinity
# virtual memory size
LimitAS=infinity
# open files
LimitNOFILE=64000
# processes/threads
LimitNPROC=64000
# locked memory
LimitMEMLOCK=infinity
# total threads (user+kernel)
TasksMax=infinity
TasksAccounting=false

# Recommended limits for for mongod as specified in
# http://docs.mongodb.org/manual/reference/ulimit/#recommended-settings

[Install]
WantedBy=multi-user.target

发送 SIGKILL 和 SIGSEGV 都会终止进程并且不会重新启动。我不确定这些是否被 systemd“捕获”，而不仅仅是重新启动。

那么有几个问题：这对于像数据库这样的高可用性服务至关重要吗？看起来确实是这样。有什么理由让 MongoDB 没有开箱即用的配置吗？

Answer 1

意外关闭绝对是强烈建议管理员干预的情况，尽管您始终可以更改部署的服务默认值。

如果mongod进程关闭的原因是不经人工干预就无法修复的不变量（例如，磁盘空间不足或数据文件损坏），则自动重新启动将无济于事，并且可能会使情况变得更糟。一般情况下，mongod不应关闭可恢复的错误。MongoDB服务器异常架构区分了每个操作的致命错误和对整个过程来说是致命的错误。进程致命错误是指继续可能导致可怕结果的情况，例如数据丢失或磁盘上的数据损坏。用户或操作系统发起的终止进程的信号（例如Linux 上的Out-of-Memory aka OOM Killer）也会导致mongod关闭。

评论中提到的一个示例错误是索引构建在某些具有旧版本 MongoDB 的辅助节点上出现段错误。使用自动服务重新启动，这种情况可能会导致无限循环，其中辅助节点可能会崩溃、重新启动、恢复索引构建、遇到相同的情况，然后重新启动……只是为了恢复注定失败的索引构建。在此重新启动循环正在进行时，辅助节点的间歇性可用性可能会影响使用辅助读取首选项或副本集其他成员的客户端（例如，重复查找上游 oplog 以恢复同步）。

作为系统管理员，我更愿意查看 MongoDB 日志并尝试了解进程关闭的原因，以便解决根本原因。理想情况下，部署将具有足够的容错能力，能够应对成员不可用的情况，以便有时间调查和纠正这种情况。

根据问题和部署（独立、副本集或分片集群）的性质，我可能还想在尝试任何自动或手动恢复之前备份数据文件。例如，在非正常关机后重新启动时，mongod有一个初始恢复阶段，该阶段将应用未完成的日志条目并运行存储引擎检查，如dbPath. 对于独立服务器，在任何恢复/修复尝试之前获取未修改数据文件的副本是谨慎的。使用副本集部署，数据已经复制到副本集的另一个成员上，因此如果标准恢复不成功，我将重新同步该成员，而不是尝试任何修复。