Ubuntu 16.04 安装 MongoDB systemd 兼容性问题与 service 文件详解

1. 为什么 Ubuntu 16.04 上装 MongoDB 不是“照着官网抄命令”就能完事？

你点开 MongoDB 官网的 Linux 安装页，复制粘贴几行 apt-get install 命令，回车一气呵成——结果 sudo systemctl start mongod 报错： Failed to start mongod.service: Unit mongod.service not found. 或者更经典的那句： System has not been booted with systemd as init system (PID 1). Can't operate.

这不是你手抖打错了，也不是网络没连上。这是 Ubuntu 16.04 这个特定版本和 MongoDB 官方包之间一场静默的“协议冲突”。

Ubuntu 16.04 是 systemd 的坚定拥护者，它把 init 系统彻底换成了 systemd，PID 1 就是 /lib/systemd/systemd 。但 MongoDB 官方在 2016–2017 年间发布的 .deb 包（尤其是 3.2、3.4 版本），其 postinst 脚本里硬编码了对 upstart 的依赖判断逻辑。它会去检查 /usr/bin/initctl 是否存在、是否是 upstart 的二进制，一旦发现系统里没有 upstart（而只有 systemd），它就直接放弃注册服务单元文件，连 /lib/systemd/system/mongod.service 都不往磁盘上写。你看到的“service not found”，本质是 MongoDB 安装脚本主动拒绝为你生成这个文件。

这解释了为什么很多人在 Ubuntu 16.04 上反复重装、清缓存、换源，最后还是卡在启动环节——问题根本不在你的操作，而在那个被时代甩在身后的安装包本身。

更麻烦的是，Ubuntu 16.04 的官方仓库（ universe ）里提供的 MongoDB 版本是 2.6.x，早已停止维护，连 TLS 1.2 都不支持，用在生产环境等于裸奔。而你从 MongoDB 官网下载的 .deb 包，又因为上述 systemd 兼容性问题，装完就是个“半成品”。这就逼着你必须亲手补全缺失的一环：一个能被 systemd 正确识别、加载、管理的 mongod.service 文件。

这不是可选项，是必经之路。跳过这一步，你永远只能用 sudo mongod --config /etc/mongod.conf 这种前台运行的方式“临时跑一下”，关掉终端、重启服务器，服务就立刻消失。真正的服务化管理，必须从写好这个 service 文件开始。

提示：别急着去网上搜现成的 service 文件模板直接复制。很多博客贴出来的内容，要么是为 Ubuntu 18.04+ 写的（默认带 ProtectHome=true ，在 16.04 上会导致权限错误），要么是为旧版 SysV init 写的（ .service 文件里还写着 Type=forking 和 PIDFile= ，这在 systemd 下已过时且易出错）。我们必须基于 Ubuntu 16.04 的内核特性、systemd 版本（229）和 MongoDB 3.4/3.6 的实际行为，手写一个“严丝合缝”的版本。

2. 手写 mongod.service 文件：每一行配置背后的实战逻辑

我们不抄模板，我们来逐行拆解一个真正能在 Ubuntu 16.04 上稳定运行的 mongod.service 文件。这个文件最终要放在 /lib/systemd/system/mongod.service ，它是整个服务生命周期的“宪法”。

[Unit]
Description=High-performance, schema-free document-oriented database
Documentation=https://docs.mongodb.org/manual
After=network.target

[Service]
Type=simple
User=mongodb
Group=mongodb
EnvironmentFile=/etc/default/mongod
ExecStart=/usr/bin/mongod --config /etc/mongod.conf
Restart=on-failure
RestartSec=10
KillSignal=SIGINT
TimeoutStopSec=300
RestartPreventExitStatus=23
LimitNOFILE=64000
LimitNPROC=64000
UMask=002
WorkingDirectory=/var/lib/mongodb
StandardOutput=journal
StandardError=journal
SyslogIdentifier=mongod

[Install]
WantedBy=multi-user.target

现在，我们一行一行说清楚“为什么这么写”，而不是“应该这么写”。

2.1 [Unit] 段：服务依赖关系不是摆设

After=network.target 这行至关重要。MongoDB 启动时需要解析主机名、绑定 IP 地址、可能还要连接其他节点（分片或副本集）。如果 network.target 还没就绪， mongod 就贸然启动，它可能拿到一个未配置好的网络接口，或者 localhost 解析失败，导致启动卡死在 Waiting for connections on port 27017 之后再无下文。 network.target 是 systemd 保证基础网络栈（IP、路由、DNS）已准备就绪的信号灯，必须等它亮了才能开工。

Documentation= 这行看似可有可无，实则是个“防呆设计”。当你执行 systemctl status mongod 时，输出里会带上这个链接。运维同事半夜被告警叫醒，一眼就能点进去查官方最新文档，而不是在 Slack 里疯狂问“这个错误码啥意思”，节省的是真金白银的时间成本。

2.2 [Service] 段：Type=simple 是唯一正确选择

这里必须强调： 绝对不要写 Type=forking 。这是旧时代 SysV init 的遗毒。MongoDB 3.2+ 的 mongod 进程默认就是以 simple 模式运行的——它不会自己 fork 出子进程然后让父进程退出；它就是那个“主进程”，PID 就是 systemd 记录的那个 PID。如果你强行写 Type=forking ，systemd 会傻乎乎地等 mongod fork 后的子进程 PID，结果等一辈子也等不到，最终超时失败，日志里全是 Failed to start mongod.service: Timeout occurred 。

User=mongodb 和 Group=mongodb 是安全底线。MongoDB 官方安装包会自动创建这个用户，但它的家目录是 /var/lib/mongodb ，shell 是 /bin/false ，完全无法登录。这是刻意为之的安全隔离。所有数据文件、日志文件的属主都必须是 mongodb:mongodb ，否则 mongod 进程以该用户身份启动后，会因权限不足而无法读写 /var/lib/mongodb 目录，报错 Permission denied 。我见过太多人因为手动 chown -R root:root /var/lib/mongodb ，结果服务死活起不来，折腾半天才发现是权限搞反了。

EnvironmentFile=/etc/default/mongod 这行是预留的“配置扩展位”。虽然默认的 /etc/default/mongod 文件是空的，但它给了你一个标准化的地方去注入额外的环境变量。比如，你想让 mongod 启动时强制使用某个特定的 LD_LIBRARY_PATH ，或者设置 MONGO_INITDB_ROOT_USERNAME （用于初始化脚本），都可以在这里写，而不用去改 ExecStart 这行命令。它让配置管理变得模块化、可审计。

ExecStart= 这行命令本身， --config /etc/mongod.conf 是关键。它告诉 mongod 去哪里读取它的核心配置。这个路径不能错，也不能省略。有些教程让你直接写 ExecStart=/usr/bin/mongod --dbpath /var/lib/mongodb --port 27017 ，这是极其危险的“裸奔”写法。它绕过了 /etc/mongod.conf 里的所有安全策略（如 security.authorization: true ）、日志配置（ systemLog.destination: file ）、存储引擎参数（ storage.wiredTiger.engineConfig.cacheSizeGB ）。生产环境必须走配置文件驱动。

Restart=on-failure 和 RestartSec=10 构成了基础的自愈能力。 on-failure 指当进程非零退出（即异常崩溃）时才重启，而不是每次 systemctl stop 都触发重启。 RestartSec=10 设置了 10 秒的冷却时间，避免进程刚起来就崩溃，形成“启动-崩溃-重启”的雪崩循环，把系统资源耗尽。这个值不是拍脑袋定的，是经过压测验证的：10 秒足够 mongod 完成一次完整的初始化（加载索引、恢复 journal），如果它 10 秒内都起不来，大概率是配置或磁盘出了硬伤，需要人工介入。

KillSignal=SIGINT 是个精妙的设计。 mongod 对 SIGINT 的处理是优雅关闭（graceful shutdown）：它会先停止接受新连接，然后等待正在执行的查询完成，最后刷写 journal 到磁盘，再退出。这比粗暴的 SIGKILL （ kill -9 ）安全一万倍，能最大程度避免数据损坏。 TimeoutStopSec=300 给了它足足 5 分钟来完成这个优雅关闭流程。对于一个拥有数 TB 数据、正在做 checkpoint 的实例，5 分钟是合理的。

LimitNOFILE=64000 和 LimitNPROC=64000 是性能调优的核心。MongoDB 是 I/O 密集型应用，一个连接对应一个文件描述符（socket），一个后台线程对应一个进程。Ubuntu 16.04 默认的 nofile 限制是 1024， nproc 是 65536。1024 个文件描述符，意味着最多同时处理 1024 个客户端连接，这在任何稍有流量的场景下都是瓶颈。 64000 是一个经过大量线上验证的保守值，既能满足绝大多数业务需求，又不会过度消耗内核资源。这个值必须在 service 文件里显式声明，因为 systemd 的 DefaultLimitNOFILE 在 16.04 上默认并不生效，必须 per-service override。

UMask=002 控制新建文件的默认权限。 002 意味着文件创建出来是 664 （rw-rw-r--），目录是 775 （rwxrwxr-x）。这确保了 mongodb 用户组内的其他成员（比如备份脚本的运行用户）可以读取日志文件，方便故障排查，同时又不会让世界可读（ 000 会变成 666 ，太危险）。

WorkingDirectory=/var/lib/mongodb 这行常被忽略，但它解决了 systemd workingdir 这个热词背后的真实痛点。 mongod 在启动时，会尝试在当前工作目录下创建一些临时文件（比如 mongod.lock ）。如果 WorkingDirectory 没指定，systemd 默认会把工作目录设为 / ，而 / 目录是 root:root 所有， mongodb 用户没有写权限，导致启动失败，报错 Unable to create /mongod.lock 。明确指定为 /var/lib/mongodb ，这个目录的属主本来就是 mongodb:mongodb ，一切水到渠成。

2.3 [Install] 段：WantedBy=multi-user.target 是服务化的入场券

multi-user.target 是 systemd 的一个“目标单元”（target unit），它代表系统已经完成了所有基础服务（网络、日志、定时任务等）的启动，进入了多用户、可登录的状态。把 mongod.service “想要加入”（ WantedBy ）这个 target，就等于告诉 systemd：“请在我进入多用户模式时，自动启动我”。这是实现开机自启的唯一标准方式。 systemctl enable mongod 命令的本质，就是在 /etc/systemd/system/multi-user.target.wants/ 目录下创建一个指向 /lib/systemd/system/mongod.service 的软链接。没有这行， enable 就是无效操作。

3. 安装与配置全流程：从零开始的每一步验证

现在，我们把前面所有的理论，落地为一份可执行、可复现、每一步都有验证点的操作清单。这不是一个“复制粘贴就完事”的脚本，而是一个“每执行一步，你都要确认一个状态”的严谨流程。

3.1 第一步：卸载所有残留，从干净状态开始

很多人的失败，源于之前多次失败安装留下的“幽灵文件”。我们必须先做一次彻底的清理。

# 1. 停止并禁用任何可能存在的 mongod 服务
sudo systemctl stop mongod
sudo systemctl disable mongod

# 2. 卸载所有 mongodb 相关的包
sudo apt-get purge mongodb-org*
sudo apt-get autoremove
sudo apt-get autoclean

# 3. 彻底删除数据和配置目录（警告：这会清空所有数据库！仅限全新安装）
sudo rm -rf /var/lib/mongodb
sudo rm -rf /var/log/mongodb
sudo rm -f /etc/mongod.conf
sudo rm -f /lib/systemd/system/mongod.service
sudo rm -f /etc/default/mongod

# 4. 清理 APT 缓存，确保下次安装拉取的是最新包
sudo apt-get clean

验证点 ：执行完以上命令后，运行 ls /var/lib/mongodb ，应该返回 No such file or directory ；运行 systemctl list-unit-files | grep mongod ，应该没有任何输出。这证明你的系统已经回到了“出厂设置”。

3.2 第二步：导入官方 GPG 密钥与源，安装 MongoDB 3.4（Ubuntu 16.04 最佳匹配版）

Ubuntu 16.04 的内核是 4.4，glibc 是 2.23。MongoDB 3.6+ 要求 glibc 2.27+，所以 3.4 是官方支持的最高版本，也是最稳定的。

# 1. 导入 MongoDB 官方 GPG 密钥（验证包签名，防止中间人攻击）
wget -qO - https://www.mongodb.org/static/pgp/server-3.4.asc | sudo apt-key add -

# 2. 创建 MongoDB 的源列表文件
echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list

# 3. 更新 APT 索引
sudo apt-get update

# 4. 安装 MongoDB 3.4 全套组件
sudo apt-get install -y mongodb-org=3.4.24 mongodb-org-server=3.4.24 mongodb-org-shell=3.4.24 mongodb-org-mongos=3.4.24 mongodb-org-tools=3.4.24

# 5. 锁定版本，防止 apt upgrade 时意外升级到不兼容的 3.6+
echo "mongodb-org hold" | sudo dpkg --set-selections
echo "mongodb-org-server hold" | sudo dpkg --set-selections
echo "mongodb-org-shell hold" | sudo dpkg --set-selections
echo "mongodb-org-mongos hold" | sudo dpkg --set-selections
echo "mongodb-org-tools hold" | sudo dpkg --set-selections

验证点 ：执行 mongod --version ，输出应为 db version v3.4.24 ；执行 dpkg -l | grep mongodb-org ，应看到所有组件的版本号都是 3.4.24 。注意，此时 systemctl status mongod 依然会报 Unit mongod.service not found ，这是预期的，因为我们还没创建 service 文件。

3.3 第三步：创建并验证 mongod.service 文件

将我们在第二部分精心编写的 service 文件内容，完整地写入系统。

# 使用 nano 编辑器（新手友好）创建文件
sudo nano /lib/systemd/system/mongod.service

把之前那段完整的 [Unit] 、 [Service] 、 [Install] 内容，一字不差地粘贴进去，保存退出（ Ctrl+O , Enter , Ctrl+X ）。

# 重新加载 systemd 配置，让新 service 文件生效
sudo systemctl daemon-reload

# 验证 service 文件语法是否正确
sudo systemctl cat mongod.service
# 这条命令应该能正常输出你刚写的内容，而不是报错

# 检查 service 文件是否被 systemd 正确识别
sudo systemctl list-unit-files | grep mongod
# 输出应为：mongod.service   disabled

验证点 ： systemctl cat mongod.service 必须成功输出，且内容与你编写的一致； list-unit-files 的输出中， mongod.service 状态是 disabled ，说明它已被识别，但尚未启用。

3.4 第四步：初始化配置文件与数据目录

MongoDB 的配置文件 /etc/mongod.conf 是它的“大脑”。我们用一个最小但安全的配置作为起点。

# 创建配置文件
sudo nano /etc/mongod.conf

写入以下内容：

# /etc/mongod.conf

# where to write logging data.
systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

# Where and how to store data.
storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true
  #  Ubuntu 16.04 默认 ext4 文件系统，无需额外配置 wiredTiger
  #  如果是 XFS，建议加上：wiredTiger:
  #    engineConfig:
  #      cacheSizeGB: 2

# how the process runs
processManagement:
  fork: false  # 重要！必须为 false，与 Type=simple 匹配
  pidFilePath: /var/run/mongodb/mongod.pid
  timeZoneInfo: /usr/share/zoneinfo

# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1  # 仅监听本地，生产环境如需远程访问，需改为 bindIp: 0.0.0.0 并配合 UFW

# security
security:
  authorization: enabled  # 强烈建议开启，这是基本安全线

# 创建日志和 PID 目录，并设置正确权限
sudo mkdir -p /var/log/mongodb /var/run/mongodb
sudo chown -R mongodb:mongodb /var/log/mongodb /var/run/mongodb /var/lib/mongodb
sudo chmod 0755 /var/run/mongodb

# 创建一个初始的 admin 用户（这是开启 authorization 后，唯一能登录的用户）
# 我们先以无认证模式启动一次，创建用户，再重启启用认证
sudo systemctl start mongod
# 等待 10 秒，让 mongod 完全启动
sleep 10
# 连接到本地数据库
mongo --eval "db.runCommand({createUser: 'admin', pwd: 'yourStrongPassword123!', roles:[{role:'root',db:'admin'}]})"
# 关闭无认证的 mongod
sudo systemctl stop mongod

验证点 ： sudo systemctl start mongod 后， sudo systemctl status mongod 应显示 active (running) ； sudo tail -f /var/log/mongodb/mongod.log 应能看到 waiting for connections on port 27017 这行日志，证明进程已就绪； mongo --eval "db.version()" 应能成功连接并返回 3.4.24 。

3.5 第五步：启用开机自启与防火墙（UFW）配置

最后一步，让服务真正融入系统生态。

# 启用开机自启
sudo systemctl enable mongod

# 启动服务
sudo systemctl start mongod

# 检查状态
sudo systemctl status mongod

# 配置 UFW（Ubuntu Firewall），只允许必要的端口
# 首先确保 UFW 已安装并启用
sudo ufw status verbose
# 如果是 inactive，先启用
sudo ufw enable

# 允许 SSH（22端口），这是远程管理的前提
sudo ufw allow OpenSSH

# 如果你确定只需要本地应用访问 MongoDB，就只允许 127.0.0.1，无需额外放行
# 如果你需要从其他服务器访问（例如应用服务器），则放行 27017 端口，但仅限于可信 IP
# sudo ufw allow from 192.168.1.100 to any port 27017

# 查看最终规则
sudo ufw status numbered

验证点 ： systemctl is-enabled mongod 应输出 enabled ； ufw status numbered 应清晰列出 OpenSSH 规则，以及（如果配置了）针对 27017 端口的精确规则。此时，你可以放心地重启服务器 sudo reboot ，重启后 systemctl status mongod 依然应该是 active (running) 。

4. 故障排查实战：从日志到命令的完整诊断链路

即使你严格按照上面的步骤操作，线上环境千变万化，总会有意想不到的状况。下面是我整理的，从“服务启动失败”这个最常见问题出发，一套完整的、可复现的排查链路。它不是罗列一堆错误代码，而是模拟一个真实运维工程师的思考过程。

4.1 现象： systemctl start mongod 后， status 显示 failed

第一步，永远是看日志。 systemctl 的日志是第一手资料。

# 查看最近 50 行 mongod 的 journal 日志
sudo journalctl -u mongod -n 50 -f

# 如果日志滚动太快，可以导出到文件分析
sudo journalctl -u mongod > mongod_debug.log

常见日志线索与对策：

• 线索1： Failed to start mongod.service: Unit mongod.service not found
  这说明 daemon-reload 没执行，或者 service 文件路径写错了（比如写成了 /etc/systemd/system/mongod.service ）。检查 ls /lib/systemd/system/mongod.service 是否存在。

• 线索2： Permission denied 或 Cannot open /var/lib/mongodb
  这是权限问题。执行 ls -ld /var/lib/mongodb ，确认输出是 drwxr-xr-x 3 mongodb mongodb ... 。如果不是，执行 sudo chown -R mongodb:mongodb /var/lib/mongodb 。

• 线索3： Failed to parse config file: /etc/mongod.conf
  YAML 格式极其敏感。最常见的错误是缩进用了 Tab 而不是空格，或者冒号后面少了空格。用 yamllint 工具检查： sudo apt-get install yamllint && yamllint /etc/mongod.conf 。

• 线索4： child process failed, exited with error number 100
  这是 MongoDB 的内部错误码，通常指向配置文件中的致命错误。重点检查 storage.dbPath 路径是否存在且可写， net.port 是否被其他进程占用（ sudo lsof -i :27017 ）。

4.2 现象：服务显示 active (running) ，但 mongo 客户端无法连接

这说明 mongod 进程起来了，但没在监听你期望的地址和端口。

# 1. 确认 mongod 进程是否真的在监听 27017
sudo ss -tuln | grep :27017
# 正常输出应为：tcp LISTEN 0 128 *:27017 *:* （表示监听所有地址）
# 如果是：tcp LISTEN 0 128 127.0.0.1:27017 *:* （表示只监听本地）

# 2. 检查 mongod 的实际绑定地址
sudo ps aux | grep mongod
# 找到类似 `/usr/bin/mongod --config /etc/mongod.conf` 的进程，确认它确实加载了配置文件

# 3. 检查配置文件中的 bindIp
sudo grep "bindIp" /etc/mongod.conf
# 如果输出是 `bindIp: 127.0.0.1`，那么它只接受本地连接。要从外部连接，必须改为 `bindIp: 0.0.0.0`，并确保 UFW 放行了该端口。

# 4. 测试本地连接
mongo --host 127.0.0.1:27017 --eval "db.runCommand({ping:1})"
# 如果这行成功，说明服务本身没问题，问题出在网络或防火墙。

4.3 现象：开启了 authorization: enabled ，但连不上，提示 not authorized on admin to execute command

这是权限配置的典型误区。 authorization: enabled 开启后， 所有数据库操作都需要先认证 ，包括 use admin 。

# 正确的连接方式（必须指定数据库和用户名）
mongo -u "admin" -p "yourStrongPassword123!" --authenticationDatabase "admin"

# 或者，在 mongo shell 里：
> use admin
> db.auth("admin", "yourStrongPassword123!")
# 返回 1 表示认证成功

# 如果你忘了密码，唯一的办法是临时关闭 authorization，重置密码
# 1. 修改 /etc/mongod.conf，注释掉 security.authorization 行
# 2. 重启 mongod: sudo systemctl restart mongod
# 3. 连接后执行: use admin; db.changeUserPassword("admin", "newPassword");
# 4. 恢复配置，重启

4.4 现象： sudo ufw allow samba command not found

这是一个典型的“混淆了不同工具”的案例。 ufw 是 Ubuntu 的防火墙管理工具， samba 是一个独立的文件共享服务。 sudo ufw allow samba 这个命令本身是错误的，因为 ufw 并不认识 samba 这个服务名。

ufw 只认识端口号或预定义的服务名（这些定义在 /etc/ufw/applications.d/ 目录下）。Samba 默认使用 137/udp , 138/udp , 139/tcp , 445/tcp 端口。

正确的做法是：

# 方案1：按端口放行（推荐，精准控制）
sudo ufw allow 137/udp
sudo ufw allow 138/udp
sudo ufw allow 139/tcp
sudo ufw allow 445/tcp

# 方案2：如果系统里有 samba 的 ufw profile（需手动创建）
# 创建 /etc/ufw/applications.d/samba
sudo nano /etc/ufw/applications.d/samba
# 写入：
[Samaba]
title=Samba file and print server
description=This option allows Samba file and print sharing.
ports=137/udp|138/udp|139/tcp|445/tcp
# 然后启用
sudo ufw allow Samba

这个例子告诉我们：遇到 command not found ，首先要确认你是否在使用正确的工具。 ufw 和 samba 是两个完全独立的软件包，它们的命令行接口互不兼容。

5. 生产环境加固与后续演进：不止于“能用”

当你成功让 MongoDB 在 Ubuntu 16.04 上稳定运行后，真正的挑战才刚刚开始。一个“能用”的数据库，离一个“可靠、安全、可维护”的生产级数据库，还有很长一段路。以下是我在多个项目中沉淀下来的、超越基础安装的加固要点。

5.1 数据持久化与备份：别让 mongodump 成为你的唯一希望

mongodump 是一个方便的逻辑备份工具，但它有严重缺陷：它需要在数据库运行时扫描所有数据，会带来显著的 I/O 和 CPU 压力，对于大库（>100GB），一次备份可能耗时数小时，期间业务响应会明显变慢。

生产级方案是组合拳：

• 文件系统快照（LVM Snapshot） ：这是最高效、最接近“零停机”的备份方式。Ubuntu 16.04 默认使用 LVM，你可以为 /var/lib/mongodb 所在的逻辑卷创建一个瞬时快照，然后在快照上运行 mongodump 。快照创建只需秒级，且对主卷 I/O 几乎无影响。

  # 假设你的 mongodb 数据在 /dev/vg00/lv_mongodb 逻辑卷上
  sudo lvcreate -L 10G -s -n lv_mongodb_snap /dev/vg00/lv_mongodb
  sudo mount /dev/vg00/lv_mongodb_snap /mnt/snapshot
  # 现在在 /mnt/snapshot 上运行 mongodump
  sudo -u mongodb mongodump --dbpath /mnt/snapshot --out /backup/dump_$(date +%Y%m%d)
  sudo umount /mnt/snapshot
  sudo lvremove -f /dev/vg00/lv_mongodb_snap
  

• Oplog 增量备份 ： mongodump 是全量。结合 MongoDB 的 oplog（操作日志），你可以实现增量备份。每天做一次全量 mongodump ，每小时用 mongodump --oplog 备份自上次以来的所有变更。恢复时，先恢复全量，再按时间顺序重放 oplog，即可恢复到任意时间点。

5.2 监控与告警：让数据库自己“说话”

一个没有监控的数据库，就像一辆没有仪表盘的汽车。Ubuntu 16.04 自带的 sysstat （ sar 命令）可以提供基础的系统指标，但 MongoDB 需要更深层的洞察。

• mongostat ：一个实时的“数据库体检仪”。它每秒刷新一次，显示 insert , query , update , delete , getmore , command 的 QPS，以及 faults （页错误，反映内存压力）、 locked % （锁等待百分比）。把它加到你的 screen 或 tmux 会话里，是日常巡检的第一步。

  # 每2秒刷新一次，显示最近10行
  mongostat -h 127.0.0.1:27017 --rowcount 10 --noheaders 2
  

• mongotop ：定位性能瓶颈的利器。它告诉你，当前数据库的读写操作，都集中在哪些集合（collection）上。如果 mongostat 显示 query QPS 很高，而 mongotop 显示 myapp.users 集合占了 90% 的读取时间，那优化方向就非常明确了：给 users 集合加索引，或者重构查询逻辑。

5.3 安全加固：从“能连上”到“连得安心”

authorization: enabled 只是安全的起点。一个完整的安全策略还包括：

• TLS/SSL 加密 ：防止数据在传输过程中被窃听。MongoDB 3.4 支持 TLS 1.2。你需要为服务器生成一个 X.509 证书（可以用 Let's Encrypt 的免费证书，或自建 CA），并在 /etc/mongod.conf 中配置：

  net:
    ssl:
      mode: requireSSL
      PEMKeyFile: /etc/ssl/mongodb.pem
      CAFile: /etc/ssl/ca.crt
  

• 网络隔离 ：不要把 MongoDB 直接暴露在公网上。最佳实践是将应用服务器和 MongoDB 服务器部署在同一 VPC（虚拟私有云）或同一局域网内，并通过 UFW 或云服务商的安全组，严格限制只有应用服务器的 IP 能访问 MongoDB 的 27017 端口。

• 最小权限原则 ：为每个应用创建独立的数据库用户，只授予其所需的最小权限。例如，一个只读报表应用，应该只被授予 read 角色，而不是 readWrite 。

  // 在 admin 数据库下执行
  use reporting_db
  db.createUser({
    user: "reporter",
    pwd: "strongPassword",
    roles: [{ role: "read", db: "reporting_db" }]
  })
  

5.4 后续演进：Ubuntu 16.04 的终点与 MongoDB 的未来

Ubuntu 16.04 的生命周期已于 2021 年 4 月结束（EOL），这意味着它不再接收任何安全更新。继续在生产环境中使用它，本身就是最大的安全风险。

迁移路径规划：

• 短期（3个月内） ：将 MongoDB 升级到 3.4 的最后一个补丁版本（3.4.24），并确保所有安全加固措施到位。这是你在 16.04 上能做的最后一步。

• 中期（6个月内） ：规划操作系统升级。Ubuntu 18.04 LTS 是一个平滑的升级目标，它原生支持 MongoDB 4.0+， systemd 兼容性完美，且有长达 5 年的安全支持。

• 长期（1年内） ：拥抱容器化。用 Docker 将 MongoDB 3.4 封装成一个镜像，部署在 Kubernetes 集群上。这样，你就可以在不改变底层 OS 的前提下，轻松地横向扩展、滚动升级、实现高可用。一个简单的 docker-compose.yml 就能启动一个单节点 MongoDB，其可维护性远超传统安装。

我在实际操作中发现，最难的从来不是技术本身，而是推动团队达成共识。当你向架构师提出“我们需要升级 Ubuntu”时，他可能会说“现在很稳定，没必要动”。这时候，拿出一份清晰的 EOL 时间表、一份对比 16.04 和 18.04 在内核、glibc、systemd 版本上的差异报告，以及一份详细的迁移风险评估和回滚计划，比任何技术争论都更有说服力。技术决策，最终是业务决策。