Ubuntu16.04下MongoDB从3.4升级至3.6后服务状态显示失败但运行正常

这种情况我碰到过好多次——看起来服务挂了，但数据库明明能正常用，本质上大多是systemd的服务配置和实际运行的MongoDB进程不匹配，或者升级过程中某个环节的配置出了小纰漏。下面一步步帮你排查修复：

1. 先确认MongoDB实际进程状态 #

先搞清楚是不是真的有mongod进程在运行，毕竟你能通过shell和Robomongo访问，大概率是进程活着但systemd没识别到：

ps aux | grep mongod

如果输出里能看到类似mongodb 1234 0.5 10.0 123456 7890 ? Ssl 10:00 0:05 /usr/bin/mongod --config /etc/mongod.conf的进程，说明数据库确实在正常运行，问题出在systemd的服务管理上。

2. 扒出服务失败的具体原因 #

这是最关键的一步，别瞎猜，直接看日志找线索：

• 查看systemd的服务日志，能看到启动失败的详细原因：

journalctl -u mongod.service -xe

• 或者直接看MongoDB自身的日志文件（默认路径）：

tail -n 50 /var/log/mongodb/mongod.log

日志里会明确告诉你问题所在——比如配置文件语法错了、权限不够、启动参数冲突等等。

3. 常见问题及修复方案 #

情况A：systemd服务文件配置错误 #

升级后可能没正确更新mongod的systemd单元文件，导致启动路径或参数不对。先检查服务文件：

cat /lib/systemd/system/mongod.service

正常的MongoDB 3.6版本，ExecStart行应该是这样的：

ExecStart=/usr/bin/mongod --config /etc/mongod.conf

如果路径不对（比如指向了旧的3.4版本的mongod），先确认当前mongod的实际路径和版本：

which mongod
mongod --version

确认是3.6版本后，修改服务文件里的ExecStart路径，然后重载systemd配置并重启服务：

sudo systemctl daemon-reload
sudo systemctl restart mongod

情况B：MongoDB配置文件兼容性问题 #

3.4到3.6有一些配置项的变化，容易踩坑：

• 如果你之前用的是mmapv1存储引擎，3.6虽然兼容，但默认是wiredTiger，需要在/etc/mongod.conf里明确指定：

  storage:
    engine: mmapv1
  

• 检查net.bindIp配置，确保允许本地访问（比如127.0.0.1或者0.0.0.0），避免服务启动时绑定端口失败。
• 验证配置文件语法：YAML格式对缩进和空格要求严格，用这个命令检查有没有语法错误：

  mongod --config /etc/mongod.conf --checkConfig
  

情况C：目录权限问题 #

升级过程中可能不小心改了数据目录或日志目录的权限，导致systemd启动mongod时无法读写：

ls -ld /var/lib/mongodb /var/log/mongodb

正确的权限应该是所有者和组都是mongodb，如果不是，修复一下：

sudo chown -R mongodb:mongodb /var/lib/mongodb /var/log/mongodb
sudo chmod -R 755 /var/lib/mongodb /var/log/mongodb

然后重启服务：

sudo systemctl restart mongod

情况D：手动启动的进程与systemd冲突 #

如果你之前是手动在shell里启动mongod（比如直接敲mongod），而不是通过systemd，那systemd会认为服务没启动，但实际进程在跑。这种情况先杀掉手动启动的进程：

sudo killall mongod

然后通过systemd重新启动服务：

sudo systemctl start mongod

4. 最后验证修复结果 #

搞定后再检查服务状态：

sudo systemctl status mongod

如果显示active (running)，同时你依然能正常通过mongo shell和Robomongo访问数据库，就彻底解决了。

内容的提问来源于stack exchange，提问作者Bmaed Riasbet