$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是否有任何理由不开箱即用？
如果mongod进程关闭的原因是无法在没有手动干预的情况下修复的不变量(例如,缺少磁盘空间或数据文件损坏),则自动重启将没有帮助,并且可能使情况变得更糟.一般来说,mongod不应该关闭可恢复的错误. MongoDB Server Exception Architecture区分了每个操作的致命错误和对整个过程致命的错误.过程致命错误是指持续存在可能导致数据丢失或磁盘损坏数据等可怕结果的情况.用户或操作系统启动的信号终止进程(例如Linux上的Out-of-Memory aka OOM Killer)也会导致mongod关闭.
注释中提到的一个示例错误是一个索引构建,它使用较旧版本的MongoDB在某些辅助节点上进行了分段.使用自动服务重新启动时,此方案可能会导致无限循环,其中辅助可能会崩溃,重新启动,恢复索引构建,遇到相同的条件,并重新启动..仅恢复注定的索引构建.虽然此重新启动循环正在进行,但辅助节点的间歇性可用性可能会影响使用辅助读取首选项或副本集的其他成员的客户端(例如,重复搜索上游oplog以恢复同步).
作为系统管理员,我更愿意查看MongoDB日志并尝试了解进程关闭的原因,以便解决根本原因.理想情况下,部署将有足够的fault tolerance能够应对不可用的成员,因此有时间调查和纠正这种情况.
根据问题和部署的性质(独立,副本集或分片群集),我可能还希望在尝试任何自动或手动恢复之前备份数据文件.例如,在非正常关闭后重新启动时,mongod具有初始恢复阶段,该阶段将应用未完成的日记帐分录并在dbPath中运行存储引擎检查(如数据文件完整性).对于独立服务器,在任何恢复/修复尝试之前,应该谨慎地获取未修改的数据文件的副本.使用副本集部署时,数据已经复制到副本集的另一个成员上,因此如果标准恢复不成功,我将re-sync this member而不是尝试任何修复.
