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 有没有理由不将其配置为开箱即用?
答案1
虽然您随时可以更改部署的服务默认设置,但意外关机绝对是强烈建议管理员干预的情况。
如果进程关闭的原因mongod
是无法在没有人工干预的情况下修复的不变量(例如磁盘空间不足或数据文件损坏),则自动重启将无济于事,并且可能会使情况变得更糟。一般来说,mongod
不应因可恢复错误而关闭。MongoDB服务器异常架构区分每个操作的致命错误和对整个进程致命的错误。进程致命错误是指继续执行可能会导致数据丢失或磁盘数据损坏等严重后果的情况。用户或操作系统发出终止进程的信号(例如内存不足又称为 OOM Killer在 Linux 上)也会导致mongod
关机。
评论中提到的一个错误示例是,使用旧版本的 MongoDB 时,索引构建在某些辅助节点上发生分段错误。在自动服务重启的情况下,这种情况可能会导致无限循环,辅助节点可能会崩溃、重启、恢复索引构建、遇到相同情况,然后重启……最终只能恢复注定失败的索引构建。在此重启循环进行期间,辅助节点的间歇性可用性可能会影响使用辅助节点读取首选项或副本集其他成员的客户端(例如,反复在上游 oplog 上寻找以恢复同步)。
作为系统管理员,我更愿意查看 MongoDB 日志并尝试了解进程关闭的原因,以便解决根本原因。理想情况下,部署将具有足够的容错能够应对成员无法到场的情况,以便有时间调查并补救情况。
根据问题和部署的性质(独立、副本集或分片集群),我可能还想在尝试任何自动或手动恢复之前备份数据文件。例如,在非正常关机后重新启动时,mongod
有一个初始恢复阶段,它将应用未完成的日记帐分录并运行存储引擎检查,例如数据文件完整性dbPath
。对于独立服务器,在尝试任何恢复/修复之前,最好先复制未修改的数据文件。对于副本集部署,数据已在副本集的另一个成员上重复,因此如果标准恢复不成功,我会重新同步此成员而不是尝试任何修复。
答案2
如果您正在使用 systemd,那么Restart=always
该[Service]
部分应该允许服务在崩溃后重新启动。
答案3
如果您确实关心高可用性,您可以运行副本集,并且可以处理 1 个或多个节点故障。
我个人管理生产中的大型分片 mongodb 部署已 5 年,我更希望实例不要自动重启,因为我想在它重新进入副本集之前调查任何问题。
https://docs.mongodb.com/manual/core/replica-set-high-availability/