1.3 安装配置与启动失败事故

1.3 安装配置与启动失败事故

本节摘要：MongoDB 安装的核心是数据目录、日志目录与配置文件三件事。本节从一次 mongod 反复退出的权限事故讲标准安装流程、配置文件写法与启动失败的四步排查法。

事故档案 03：起不来的服务

运维新人用 root 手动建了 /data/db 并启动过一次 mongod，之后交给 systemd 以 mongodb 用户拉起，服务无限重启。日志里的关键一行：

exception in initAndListen: NonExistentPath: Data directory /data/db not found., terminating
​

有时是另一种：Permission denied。根因都是目录属主不是运行 mongod 的用户。Linux 下 90% 的"装完起不来"都属于这一族。

标准安装流程（Linux 为例）

# 1. 配置软件源后安装
sudo apt-get install -y mongodb-org
# 2. 规划目录并交给运行用户
sudo mkdir -p /data/db /var/log/mongodb
sudo chown -R mongodb:mongodb /data/db /var/log/mongodb
# 3. 用配置文件启动
sudo -u mongodb mongod --config /etc/mongod.conf
​

配置文件是生产的正确打开方式，裸参数启动只适合一次性实验：

storage:
  dbPath: /data/db
  journal:
    enabled: true
systemLog:
  destination: file
  path: /var/log/mongodb/mongod.log
  logAppend: true
net:
  port: 27017
  bindIp: 127.0.0.1   # 只本机可连，安全基线
processManagement:
  fork: true
​

安装检查路线

⚠️ 常见坑：bindIp 写成 0.0.0.0 且没开认证，等于把数据库裸放到公网——第 9 章的拖库事故正是这么开始的。

启动失败四步排查法

这次事故看起来低级，但排查思路可以复用到所有"服务起不来"的场景。

第一步读日志，不要猜。systemLog 指向的文件里，mongod 退出前总会留下原因，常见有四种：NonExistentPath 是目录不存在，Permission denied 是属主不对，Address already in use 是端口被占（多半是上次手动启动的进程没退干净），Unrecognized option 是配置文件里写了当前版本已移除的项。第二步查目录与属主，用 namei 逐级看路径上每一层的权限，比肉眼看 ls 更可靠：

namei -l /data/db
# drwxr-xr-x mongodb mongodb /data/db   ← 属主正确
ps aux | grep mongod      # 找残留进程
ss -lntp | grep 27017     # 确认端口占用者
​

第三步验证配置文件本身。YAML 对缩进敏感，空格与制表符混用、层级少缩进一格，都会得到难懂的报错，用 mongod --config 检查模式启动一次能在前台直接看到解析错误。第四步用最小配置启动：只留 dbPath 与 port 两项，能起来再逐项加回，二分定位出问题的配置项。

配置项取舍

生产配置文件里有几组参数值得逐个想清楚，而不是抄模板：

混部是最容易被忽略的场景：一台 64GB 的机器上同时跑应用和 mongod，默认缓存会拿走 30 多 GB，应用侧一路 OOM。显式设置 cacheSizeGB，把资源边界画清楚，比事后排查内存争抢省力得多。

Windows 环境的坑略有不同：路径要写正斜杠或双反斜杠，服务安装用 sc create 或官方安装器的服务选项，数据目录同样要保证运行账户有完整控制权限；杀毒软件实时扫描数据文件会造成周期性写入卡顿，把 dbPath 加入排除列表是标准动作。

# Windows 下以服务方式安装并指定配置
mongod --config "C:\Program Files\MongoDB\Server\7.0\bin\mongod.cfg" --install --serviceName MongoDB
net start MongoDB
# 验证
mongosh --quiet --eval 'db.adminCommand({ getCmdLineOpts: 1 }).parsed.storage.dbPath'
​

边界情况：安全子系统与资源限制

四步排查法覆盖了大多数场景，但有三类环境因素常被漏掉。一是 SELinux 或 AppArmor：目录属主明明正确，mongod 仍读不了数据文件，审计日志里会留下 avc denied 记录，红帽系机器上先查这个。二是 systemd 的资源限制：默认 LimitNOFILE 只有 1024，连接数一上来 mongod 就报 too many open files，服务单元里要显式调到 64000 以上。三是 NUMA 架构的机器，跨节点访问内存会让写入延迟抖动，用 numactl --interleave=all 包一层启动命令是老牌运维的习惯动作。

# 快速确认三类问题是否命中
ausearch -m avc -ts recent | grep mongod   # SELinux 拦截记录
cat /proc/$(pidof mongod)/limits | grep files   # 打开文件数上限
numactl --hardware | head -4               # 是否 NUMA 机器
​

这三个点在事故复盘里出现率不高，因为一旦命中，日志现象都很怪：不是明确的报错，而是无规律的卡顿与偶发失败。把这三条命令收进部署检查单，排查时能省掉大量无效猜测。

本节要点回顾

• 安装三件事：目录、属主、配置文件；
• 配置文件优先：生产不用裸参数启动；
• 排查四步：读日志、查目录属主、查端口、查 YAML 缩进；
• 安全基线：bindIp 限本机，认证见第 9 章。