网站搜索

如何在 Ubuntu 上安装 MongoDB

介绍

MongoDB 是最受欢迎的开源 NoSQL 数据库之一，广泛用于需要灵活数据结构、高度可扩展性和快速性能的应用程序。它以文档为导向的格式存储数据，使用类似 JSON 的对象，使其非常适合现代的网页、移动和分析工作负载。开发者喜欢 MongoDB，因为它具有动态模式、自动分片和内置复制功能，支持水平扩展和高可用性。结合 Ubuntu 的稳定性和安全性，MongoDB 为运行可靠高效的数据库驱动应用程序提供了坚实的基础。

在本文中，我们将讲解如何在 Ubuntu 24.04 LTS 上安装、配置和维护 MongoDB 8.2。我们涵盖了每一个关键步骤，从准备服务器和启用安全功能，到优化性能、设置复制与备份，以及排除常见问题。到最后，您将拥有一个生产就绪的 MongoDB 部署，具备适当的安全保护、监控和长期使用的优化配置。无论您是为开发、测试还是完整的生产环境部署 MongoDB，本指南都提供了详细的操作说明和运行的最佳实践，帮助您高效地使用 MongoDB。

主要要点：

  • 使用官方的 MongoDB 仓库安装最新的稳定版本，而不是依赖包含过时软件包的 Ubuntu 默认仓库。
  • 将 MongoDB 作为 systemd 服务进行管理，使用标准命令如 systemctl start mongod 和 systemctl enable mongod 来控制和监控数据库进程。
  • 仔细理解和配置 /etc/mongod.conf，因为它定义了存储、日志、网络、安全和复制的关键设置。
  • 通过启用身份验证、限制网络访问、配置防火墙以及为传输中的数据启用 TLS 加密来保护您的 MongoDB 部署。
  • 遵循日常维护操作，包括定期备份、系统监控和日志轮换，以保持数据库的可靠性并防止数据丢失。
  • 通过使用副本集实现高可用性或通过分片处理大型数据集和分布式工作负载，来适当扩展 MongoDB。
  • 根据您的需求在自托管和托管部署之间进行选择：自托管 MongoDB 提供完全控制，而像 MongoDB Atlas 这样的托管服务则简化了扩展和维护。
  • 使用 MongoDB 的诊断工具和日志进行故障排除，例如 mongostat、mongotop 以及系统日志，以高效识别和解决性能、连接或身份验证问题。

先决条件

要跟随本教程，您需要：

  • 一台运行 Ubuntu 24.04 LTS 的服务器。该服务器应拥有一个具有管理员权限的非 root 用户，并安装和配置了 UFW（简易防火墙）。请参考我们的 Ubuntu 初始服务器设置指南来进行设置。

从官方仓库安装 MongoDB

Ubuntu 24.04 在其默认的软件包库中包含了一个 MongoDB 版本，但通常是过时的。对于生产系统，您应该始终直接从 官方 MongoDB 仓库 安装 MongoDB。这可以确保您获得最新的稳定版本（撰写本文时为 8.2），以及及时的安全性和维护更新。

让我们将 MongoDB 仓库添加到系统的 APT 源中，导入用于验证软件包的 GPG 密钥，然后安装数据库。

1. 导入 MongoDB GPG 密钥

APT 使用 GPG 密钥来验证软件包的真实性。如果没有这个，您的系统将不会信任 MongoDB 的软件仓库。

运行以下命令以导入 MongoDB 8.0 的公钥：

curl -fsSL https://www.mongodb.org/static/pgp/server-8.0.asc | sudo gpg -o /usr/share/keyrings/mongodb-server-8.0.gpg --dearmor

这就是它的作用：

  • curl -fsSL 安静地从 MongoDB 官方服务器获取 GPG 密钥。
  • --dearmor 将密钥从 ASCII 装甲格式转换为与 APT 兼容的二进制密钥环格式。
  • 输出已保存到 /usr/share/keyrings/mongodb-server-8.0.gpg，这是受信任密钥的标准位置。

如果命令成功完成且未出现错误，则密钥已成功添加。

2. 添加 MongoDB 仓库

接下来，创建一个新的存储库列表文件，指向 MongoDB 的 Ubuntu 24.04（“Noble”）官方软件包源。

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.2 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-8.2.list

此命令的每个部分都有明确的用途：

  • deb 告诉 APT 这是一个二进制软件包仓库（与 deb-src 用于源代码相对）。
  • arch=amd64,arm64 将其限制为 MongoDB 支持的 64 位 Intel/AMD 和 ARM 架构。
  • signed-by=... 确保 APT 使用特定的 MongoDB 密钥（如上所添加）来验证下载内容。
  • https://repo.mongodb.org/apt/ubuntu 是 MongoDB 官方 APT 仓库的基本 URL。
  • noble/mongodb-org/8.2 指定了 Ubuntu 发行版代号（noble=Ubuntu 24.04）和 MongoDB 版本（8.2）。
  • multiverse 是 Ubuntu 的第三方软件组件部分。

3. 更新您的软件包索引

添加新仓库后，您必须刷新系统的本地可用软件包列表，以便 APT 识别新的源：

sudo apt update

APT 将下载最新的软件包列表并使用 GPG 密钥进行验证。如果你在软件源列表中看到 MongoDB，说明你的配置是正确的。

4. 安装 MongoDB

现在安装 MongoDB 及其相关工具：

sudo apt install -y mongodb-org

-y 参数会自动确认安装提示。

这将安装一组相关的包，包括：

  • mongodb-org-server：MongoDB 服务器守护进程（mongod），负责数据库的存储和操作。
  • mongodb-org-mongos：用于分布式部署的分片路由器。
  • mongodb-org-shell：用于连接 MongoDB 的交互式命令行客户端（mongosh）。
  • mongodb-org-tools：备份和恢复工具（mongodump、mongorestore、bsondump 等）。

安装完成后，二进制文件将被放置在 /usr/bin/ 下，配置文件位于 /etc/mongod.conf。

5. 验证安装

您可以通过检查版本来验证 MongoDB 8.2 是否已成功安装：

mongod --version

你应该看到类似以下的输出：

db version v8.2.3
Build Info: {
    "version": "8.2.3",
    "gitVersion": "36f41c9c30a2f13f834d033ba03c3463c891fb01",
    "openSSLVersion": "OpenSSL 3.0.13 30 Jan 2024",
    "modules": [],
    "allocator": "tcmalloc-google",
    "environment": {
        "distmod": "ubuntu2404",
        "distarch": "x86_64",
        "target_arch": "x86_64"
    }
}

如果你看到这个，说明 MongoDB 已正确安装并可以作为服务启动。

启动和管理 MongoDB 服务

当你在 Ubuntu 上安装 MongoDB 时，安装包会自动包含一个名为 mongod.service 的 systemd 服务单元。这种集成允许 MongoDB 使用 Ubuntu 的标准服务管理命令像 Nginx、PostgreSQL 或其他主要守护进程一样干净地启动、停止和重启。

启动 MongoDB 服务

默认情况下，MongoDB 在安装后不会自动启动。要手动启动它，请使用以下命令：

sudo systemctl start mongod

如果命令运行没有错误，服务现在应该处于活动状态。你可以通过以下方式确认：

sudo systemctl status mongod

示例输出：

● mongod.service - MongoDB Database Server
     Loaded: loaded (/usr/lib/systemd/system/mongod.service; disabled; preset: enabled)
     Active: active (running) since Tue 2026-01-06 07:08:28 UTC; 5s ago
       Docs: https://docs.mongodb.org/manual
   Main PID: 12462 (mongod)
     Memory: 195.4M (peak: 277.1M)
        CPU: 739ms
     CGroup: /system.slice/mongod.service
             └─12462 /usr/bin/mongod --config /etc/mongod.conf

这一行 “Active: active (running)” 确认数据库正在运行并正常工作。

如果你看到的是“失败”或“不活动”，请直接跳到检查 MongoDB 日志部分进行故障排除。

启用 MongoDB 开机启动

大多数生产系统要求数据库在重启后自动启动。要使 MongoDB 在开机时启动，请运行：

sudo systemctl enable mongod

这会在 /etc/systemd/system/multi-user.target.wants/ 中创建一个符号链接，告诉 systemd 每当系统进入多用户模式（服务器的标准操作模式）时自动启动该服务。

你可以通过以下方式确认更改：

systemctl is-enabled mongod

预期输出：

enabled

如果你想要禁用自动启动（用于维护或测试），请使用：

sudo systemctl disable mongod

验证 MongoDB 操作

一旦 MongoDB 运行起来，最好确认它是否正常响应。

运行以下命令以连接到数据库并检查其连接状态：

mongosh --eval "db.runCommand({ connectionStatus: 1 })"

这个命令：

  • 打开一个临时的 shell 会话（mongosh 是新的 MongoDB shell，用来替代旧的 mongo 客户端）。
  • 直接在本地实例上运行connectionStatus命令。
  • 显示连接结果，无需停留在终端中。

示例输出：

{
  authInfo: { authenticatedUsers: [], authenticatedUserRoles: [] },
  uuid: UUID('be686f2a-9cb3-41c1-aad2-8849367de4e5'),
  ok: 1
}

"ok": 1 的值确认服务器运行正常，并在端口 27017 接受连接。

管理 MongoDB 服务生命周期

一旦你确认 MongoDB 正在运行，了解如何在日常操作中安全地管理它会很有帮助。

以下是主要命令：

命令描述
sudo systemctl stop mongod
优雅地停止 MongoDB 服务。
sudo systemctl start mongod
如果服务已停止，则启动该服务。
sudo systemctl restart mongod
重启服务（在配置更改后非常有用）。
sudo systemctl reload mongod
在不完全重启的情况下重新加载配置（适用于有限场景）。
sudo systemctl disable mongod
防止服务在启动时自动启动。
sudo systemctl status mongod
显示当前状态和最近的日志。

在编辑 /etc/mongod.conf 后，重启服务 (restart) 尤为重要。这可以确保您的配置更改被加载。

检查 MongoDB 日志

如果 MongoDB 无法启动或行为异常，你的首要排查步骤应该是查看日志。

MongoDB 日志位于：

/var/log/mongodb/mongod.log

您可以使用以下命令查看最后 20 行：

sudo tail -n 20 /var/log/mongodb/mongod.log

常见的日志信息包括：

  • “等待端口27017的连接”：MongoDB已成功启动并准备就绪。
  • “数据目录 /var/lib/mongodb 未找到”：请检查数据路径是否存在并具有正确的权限。
  • “地址已被使用”：另一个进程已经在使用端口 27017。
  • “权限被拒绝”：确保 MongoDB 用户（mongodb）拥有其数据和日志目录的所有权。

你也可以使用 journalctl 查看 systemd 管理的特定服务日志：

sudo journalctl -u mongod --since "5 minutes ago"

在系统启动时测试 MongoDB

在重启后验证 MongoDB 是否会自动启动是一个好习惯，尤其是在部署应用程序之前。

要重启，请运行：

sudo reboot

在服务器重启后，重新登录并检查服务：

sudo systemctl status mongod

如果显示 “active (running)”，说明您的配置是正确且持久的。

了解 MongoDB 配置设置

当你安装 MongoDB 时，其行为由位于 /etc/mongod.conf 的单个配置文件控制。

此文件定义了 MongoDB 的运行方式：从数据存储位置，到日志记录活动方式、监听的 IP 地址，以及启用的安全机制。理解此文件非常关键，尤其是如果你计划在生产环境中运行 MongoDB。此文件中的设置相当于对应的命令行选项，但使用配置文件可以简化服务器管理，尤其是对于较大或自动化的部署。

配置文件概览

MongoDB 的配置文件使用 YAML 语法，对缩进很敏感。这意味着在编辑时必须使用空格（不能使用制表符），即使多一个或少一个空格也可能导致配置出错。

您可以使用以下方式查看文件的当前内容：

sudo cat /etc/mongod.conf

默认文件看起来是这样的：

# mongod.conf

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

net:
  port: 27017
  bindIp: 127.0.0.1

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

让我们逐节来分析这个内容。

storage 部分

本节定义了 MongoDB 存储数据的位置以及如何管理日志记录（确保数据持久性）。

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

  • dbPath：这是 MongoDB 存储其数据库、集合和索引的目录。默认情况下，它指向 /var/lib/mongodb。如果你更改此路径，请确保目录存在且归 mongodb 用户所有：

    sudo mkdir -p /data/mongodb

sudo chown -R mongodb:mongodb /data/mongodb

  • journal.enabled：当设置为 true 时，MongoDB 会维护一个日志文件，帮助在系统崩溃或意外关闭时进行恢复。日志会将更改写入一个单独的日志文件，然后再提交到数据文件，从而防止数据损坏。在生产系统中应始终启用此功能。

提示： 对于 WiredTiger，将日志文件分离到另一块磁盘通常不会提升性能。这种优化方法在较旧的存储引擎中可能适用，但现在已不再推荐。

systemLog 部分

这控制了 MongoDB 如何以及在何处写入日志。

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log
  • destination：指定日志写入位置。默认值 file 会将日志写入文件；如果你希望 MongoDB 日志与系统日志集成，可以将其更改为 syslog。
  • logAppend：当设置为 true 时，MongoDB 会将新的日志条目追加到现有文件，而不是在重启时覆盖它。
  • path：日志文件的绝对路径。

你可以直接查看日志：

sudo tail -f /var/log/mongodb/mongod.log

如果你的日志文件变得过大，考虑使用像 logrotate 这样的工具启用日志轮换，或配置系统日志自动轮换。

net 部分

本节定义了 MongoDB 如何监听传入的网络连接。

net:
  port: 27017
  bindIp: 127.0.0.1
  • port：MongoDB 的默认端口是 27017。如果您在同一主机上运行多个数据库服务，可以更改此端口。
  • bindIp：这控制 MongoDB 监听的网络接口。

默认情况下，它仅限于 127.0.0.1（本地回送地址），意味着只接受本地连接。这是一个关键的安全默认设置，直到您明确允许之前，会阻止远程访问。

如果你打算从另一台机器连接（例如，网页服务器或远程应用程序），你可以将其修改为：

bindIp: 127.0.0.1,192.168.1.100

或者，监听所有接口（在生产环境中请谨慎使用）：

bindIp: 0.0.0.0

安全提示：如果启用远程访问，请务必启用身份验证和防火墙规则，以限制可以连接的 IP 地址。

安全 部分

MongoDB 默认情况下安装时未启用身份验证。任何可以连接到数据库的人都可以读取或修改数据。这对于测试来说没问题，但对于任何真实系统都是一个安全威胁。要启用基于用户的身份验证，请添加以下部分：

security:
  authorization: enabled

启用此功能后，MongoDB 将要求用户在执行操作之前使用用户名和密码进行身份验证。

你将在 保护 MongoDB 部分详细配置身份验证。

本节中的其他可选设置包括：

  • keyFile：用于副本集在集群节点之间进行身份验证。
  • javascriptEnabled：启用或禁用服务器端 JavaScript 执行（除非必要，建议保持禁用）。

processManagement 部分

本节控制 MongoDB 如何处理进程管理和运行时信息。

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

这主要是信息性内容；它确保 MongoDB 能够访问时区数据以进行时间戳转换。在高级部署中，如果 MongoDB 手动启动而没有使用 systemd，你还可以在这里启用 分叉（用于后台操作）。

复制 和 分片 部分（可选）

在全新安装中你看不到这些部分，但它们在多节点或分布式设置中会被使用。

启用副本集的示例：

replication:
  replSetName: "rs0"

这告诉 MongoDB 以名为 rs0 的副本集的一部分启动。然后，您可以在 MongoDB shell 中进行初始化并添加成员。

用于分片：

sharding:
  clusterRole: "shardsvr"

这定义了节点在分片集群中的角色。

setParameter 部分

此可选部分允许您覆盖运行时参数，以微调 MongoDB 的行为。

示例：

setParameter:
  enableLocalhostAuthBypass: false

将此设置为 false 可确保即使是本地连接也需要身份验证。其他参数可以控制查询超时、游标行为或诊断日志记录。

进行和应用更改

每当您修改 /etc/mongod.conf 时，您需要重启 MongoDB 才能使更改生效：

sudo systemctl restart mongod

然后验证服务是否正在运行：

sudo systemctl status mongod

如果 MongoDB 无法重新启动，请检查语法错误（YAML 缩进错误很常见）或查看日志：

sudo tail -n 20 /var/log/mongodb/mongod.log

示例：安全且适合生产的配置

这是一个针对 Ubuntu 24.04 的干净、面向生产环境的 mongod.conf 示例：

# mongod.conf — Example production configuration

storage:
  dbPath: /data/mongodb
  journal:
    enabled: true
  engine: wiredTiger

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

net:
  port: 27017
  bindIp: 127.0.0.1,192.168.10.10

security:
  authorization: enabled
  javascriptEnabled: false

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

replication:
  replSetName: "rs0"

setParameter:
  enableLocalhostAuthBypass: false

此配置：

  • 启用身份验证
  • 使用 WiredTiger（默认存储引擎）
  • 仅绑定到特定的受信任接口
  • 为副本集初始化准备实例
  • 将所有操作记录到专用日志文件中

保障 MongoDB 安全

MongoDB 的灵活性使其非常强大，但这也意味着不安全的配置很容易导致数据泄露。在 MongoDB 的早期，许多服务器在没有认证的情况下对互联网开放，攻击者只需连接到端口 27017 就可以列出、修改甚至删除数据库。

如今，MongoDB 默认配置更加安全，但启用身份验证、网络限制和加密仍然取决于你自己。

启用身份验证

默认情况下，MongoDB 启动时 未启用身份验证。这意味着任何能够连接到数据库的人都可以运行管理命令、删除集合或修改数据而不受限制。为了防止这种情况，MongoDB 使用一个 基于角色的访问控制（RBAC） 系统，需要你显式启用。

  1. 打开 MongoDB 配置文件：

    sudo nano /etc/mongod.conf

  2. 找到 security 部分，如果不存在，则创建一个：

    security:
  authorization: enabled

  3. 保存并退出（Ctrl+O，然后 Ctrl+X）。

  4. 重新启动 MongoDB 以使更改生效：

    sudo systemctl restart mongod

MongoDB 在新部署时提供了一个 临时 本地主机身份验证绕过，以便可以创建第一个管理员用户。一旦存在管理员用户或启用了某些安全设置（如 keyFile 或 clusterAuthMode），此绕过会自动禁用。

这意味着您可以在全面执行开始之前安全地创建您的第一个管理员用户。

创建第一个管理员用户

管理员用户是 MongoDB 身份验证系统的基础。它有权限创建其他用户、定义角色以及授予对特定数据库的访问权限。

要创建此账户：

  1. 启动本地 MongoDB shell：

    mongosh

  2. 切换到 admin 数据库，该数据库存储用户凭证和角色定义：

    use admin

  3. 使用以下命令创建用户：

    db.createUser({
  user: "admin",
  pwd: "StrongPasswordHere",
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" },
    "readWriteAnyDatabase"
  ]
})

    让我们分解一下：

    • userAdminAnyDatabase 允许此用户在所有数据库中创建、修改和删除用户。
    • readWriteAnyDatabase 提供全局的读取和写入权限。（如果需要更严格的仅限管理员的用户，可以省略此权限。）

    此命令会将新文档写入 MongoDB 的 admin 数据库中的 system.users 集合。您可以通过随后列出用户来验证这一点：

    show users

  4. 退出 shell：

    exit

  5. 以管理员用户重新连接以确认现在已启用身份验证：

    mongosh -u admin -p --authenticationDatabase admin

认证后，您可以运行以下管理命令：

show dbs

如果 MongoDB 在提示输入密码并且只有在通过身份验证后才授予访问权限，RBAC 就正常工作。

最佳做法： 始终使用长且随机生成的密码，或将 MongoDB 与像 HashiCorp Vault 这样的密码管理系统集成。

为应用程序创建基于角色的用户

在生产环境中，您的应用程序绝不应该使用管理员账户。相反，应为每个应用程序创建专用用户，每个用户只拥有其所需的权限。

例如，要为管理特定数据库中数据的网络应用程序创建用户：

use myappdb
db.createUser({
  user: "appuser",
  pwd: "AppPassword123",
  roles: [ { role: "readWrite", db: "myappdb" } ]
})
  • readWrite 允许应用程序仅对该数据库执行所有标准的 CRUD 操作（插入、查询、更新、删除）。
  • 它无法创建其他用户、修改系统集合或访问其他数据库。

您可以列出数据库的所有用户，方法如下：

show users

提示： 始终根据应用程序或环境区分用户（例如，appuser_prod 和 appuser_staging），以便可以独立轮换凭据。

限制网络访问

即使启用了身份验证，将 MongoDB 暴露在公共网络上也是危险的。自动扫描器经常扫描开放端口（特别是 27017，默认的 MongoDB 端口），并尝试进行暴力破解攻击或利用配置错误的实例。

默认情况下，MongoDB 仅监听 127.0.0.1，即本地接口。如果你的应用程序和 MongoDB 服务器在同一主机上，你无需更改任何设置。但是，如果你的应用程序需要远程连接，你需要显式地将特定的 IP 地址加入白名单。

  1. 编辑配置文件：

    sudo nano /etc/mongod.conf

  2. 找到 net 部分并更新它：

    net:
  port: 27017
  bindIp: 127.0.0.1,192.168.10.50

    将 192.168.10.50 替换为您信任的应用服务器的 IP 地址。这可确保 MongoDB 仅接受来自本地主机和该特定远程主机的连接。

  3. 重新启动服务以应用更改：

    sudo systemctl restart mongod

  4. 确认活动绑定：

    sudo ss -tulpn | grep mongod

您应该能看到 MongoDB 同时在 127.0.0.1:27017 和您指定的 IP 上监听。

注意：除非有严格的网络级防火墙规则，否则不要在裸机或虚拟机部署上使用 bindIp: 0.0.0.0。在容器化或编排环境中，通常需要使用 0.0.0.0，但仍必须通过防火墙或网络策略进行保护。

配置 Ubuntu 防火墙（UFW）

即使 MongoDB 只监听某些接口，最好还是在操作系统层面加强网络安全。

Ubuntu 的 UFW 提供了一种简单的方法来控制入站和出站连接。

  1. 验证 UFW 是否已安装并处于激活状态：

    sudo ufw status

    如果显示为不活动，请启用它：

    sudo ufw enable

  2. 仅允许来自受信任 IP 的 MongoDB 连接。例如，如果您的应用服务器的 IP 是 192.168.10.50:

    sudo ufw allow from 192.168.10.50 to any port 27017

  3. 检查规则是否已添加：

    sudo ufw status numbered

    你应该看到一个允许从指定来源访问端口 27017 的条目。

  4. 可选择性地，明确拒绝所有其他访问 MongoDB 的流量：

    sudo ufw deny 27017/tcp

这种组合，即 MongoDB 配置中的 bindIp 与有选择的 UFW 规则，可以确保只有已知系统能够访问你的数据库，即使其他进程尝试将其暴露。

注意： 对于云部署（如 Linux-Console.net），配置网络安全组或 VPC 防火墙规则作为额外的保护层。

启用 TLS/SSL 加密

到目前为止，您已经确保只有受信任的用户和 IP 可以访问 MongoDB。下一步是保护传输中的数据。

当客户端连接到 MongoDB 时，所有数据（包括身份验证凭证和查询）默认以明文传输。TLS 会加密这些数据，从而防止窃听或篡改。

生成或获取证书

在生产环境中，使用来自受信任证书颁发机构（CA）的证书。对于测试或内部部署，您可以生成自签名证书：

sudo mkdir -p /etc/ssl/mongodb

sudo openssl req -newkey rsa:4096 -new -x509 -days 365 -nodes -out /etc/ssl/mongodb/mongodb.crt -keyout /etc/ssl/mongodb/mongodb.key -subj "/CN=$(hostname)"

这会创建：

  • mongodb.crt：公用证书
  • mongodb.key：私钥

将它们合并为一个 PEM 文件（MongoDB 所需）:

sudo cat /etc/ssl/mongodb/mongodb.key /etc/ssl/mongodb/mongodb.crt | sudo tee /etc/ssl/mongodb/mongodb.pem

sudo chmod 600 /etc/ssl/mongodb/mongodb.pem

sudo chown mongodb:mongodb /etc/ssl/mongodb/mongodb.pem

这些权限确保只有 mongodb 用户可以访问密钥文件。

更新配置文件

编辑 /etc/mongod.conf 并找到 net 部分。在其下添加一个新的 tls 块:

net:
  port: 27017
  bindIp: 127.0.0.1,192.168.10.50
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb/mongodb.pem
  • mode: requireTLS 意味着 MongoDB 将拒绝任何未加密的连接。
  • certificateKeyFile 指定了合并后的 PEM 文件路径。

重启 MongoDB 以应用更改：

sudo systemctl restart mongod

使用 TLS 连接

在使用 mongosh 连接时，现在必须指定 --tls 选项：

mongosh --tls --host 192.168.10.50 -u admin -p --authenticationDatabase admin

如果连接成功并且出现提示，则说明您的 TLS 配置正常。

你可以使用 OpenSSL 检查连接来验证加密情况：

openssl s_client -connect 192.168.10.50:27017

输出应显示证书链和加密详情，例如：

SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

这确认了您的 MongoDB 服务器现在正在进行端到端的流量加密。

专业提示： 在副本集启用 TLS 时，请配置 keyFile 和 clusterAuthMode（通常设置为 x509 或 keyFile），以便节点之间可以安全地相互认证。

验证您的安全状况

一旦一切配置完成，值得再仔细检查一下你的设置。

  1. 检查 MongoDB 是否仅绑定到允许的 IP：

    sudo ss -tulpn | grep mongod

    您应该仅允许来自 127.0.0.1 和您信任的 IP 的连接。

  2. 确保强制进行身份验证。尝试在未提供凭证的情况下连接：

    mongosh

    你应该会收到身份验证错误。

  3. 验证是否需要 TLS。尝试在没有 --tls 的情况下连接：

    mongosh --host 192.168.10.50 -u admin -p --authenticationDatabase admin

    如果连接失败并显示关于 TLS 要求的消息，这表明您的加密已正确执行。

  4. 检查 MongoDB 的内部安全参数：

    mongosh -u admin -p --authenticationDatabase admin --eval "db.runCommand({ getParameter: 1, tlsMode: 1 })"

    如果 tlsMode 返回 "requireTLS"，则表示加密已确认启用。

在配置了身份验证、访问控制、网络限制和 TLS 之后，你的 MongoDB 实例现在已经针对最常见的攻击向量进行了加固。

操作最佳实践

一旦 MongoDB 安装并得到安全保护，接下来的主要任务就是有效地维护它。即使是经过精心配置的数据库，如果没有定期维护也可能变得不可靠。日常操作，如备份、监控和系统更新，能够确保 MongoDB 随着时间的推移保持高性能、稳定性和可恢复性。

备份 MongoDB 数据

一个周密的备份策略对任何生产数据库都是至关重要的。备份可以让您在硬件故障、软件漏洞或意外删除时快速恢复。MongoDB 支持逻辑备份和物理备份，每种备份适用于不同的场景。

使用 mongodump 进行逻辑备份

逻辑备份使用 mongodump 工具以 BSON 格式捕获数据库内容。这种方法可移植、可读性强，并且易于自动化。

要创建所有数据库的完整备份，请运行：

mongodump --out /backups/mongodb/$(date +%F)

此命令将在 /backups/mongodb/ 下创建一个以当前日期命名的目录，并将所有 BSON 转储存储在其中。

如果启用了身份验证，请使用包含凭据的 URI 连接字符串：

mongodump --uri="mongodb://admin:YourPassword@localhost:27017/admin" --out /backups/mongodb/$(date +%F)

你也可以备份特定的数据库：

mongodump --db=myappdb --out /backups/mongodb/$(date +%F)

要从逻辑备份恢复，请使用 mongorestore：

mongorestore /backups/mongodb/2026-01-05/

或者恢复单个数据库：

mongorestore --db=myappdb /backups/mongodb/2026-01-05/myappdb

逻辑备份灵活且易于编写脚本，但对于非常大的数据集，完成时间可能较长。

建议： 使用 cron 任务或 systemd 定时器安排每日逻辑备份，并始终在暂存服务器上验证恢复过程，然后再在生产环境中依赖备份。

物理备份（文件系统快照）

物理备份直接从存储卷中捕获数据库文件。这种方法对于大型数据库来说更快且更节省空间，但需要一致性的快照以避免损坏。

如果你使用日志记录（默认启用），则可以在 MongoDB 运行时进行卷快照。只要启用了日志记录，WiredTiger 就支持在 MongoDB 运行时进行崩溃一致性快照。对于完全应用一致性快照，建议停止 MongoDB，但不是必须的：

sudo systemctl stop mongod

使用您的云提供商或存储系统进行快照，然后重启服务：

sudo systemctl start mongod

尽可能将快照存储在异地或不同区域。这可以防止数据中心故障或意外的本地删除。

监控 MongoDB 健康状况

监控对于在问题影响用户之前进行预防至关重要。MongoDB 提供了内置的命令行工具，同时也支持外部监控系统。

使用内置工具

mongostat 工具显示实时数据库指标，例如每秒操作数、内存使用情况和活动连接。运行方式如下：

mongostat --uri "mongodb://admin@localhost:27017/?authSource=admin"

这会生成一个实时表格，显示插入、查询、更新和删除操作。每一列代表一个关键绩效指标，例如脏内存页的比例或活动连接的数量。

mongotop 工具主要关注 MongoDB 在每个集合上的读写时间。要每两秒运行一次，请使用：

mongotop 2

这对于识别经历大量 I/O 的集合非常有用。

使用外部监控工具

为了实现持续的可见性和警报，您可以将 MongoDB 与以下外部系统集成：

  • MongoDB Atlas 监控，即使是自托管集群也适用。
  • 使用 MongoDB 导出器进行时间序列仪表板的 Prometheus 和 Grafana。
  • Percona 监控与管理（PMM），一套完整的开源监控套件。
  • 常用的系统工具，如 Netdata、Zabbix 或 Datadog。

需要监控的重要指标包括：

  • 内存使用率和缓存命中率
  • 磁盘 I/O 延迟和吞吐量
  • 连接数和队列长度
  • 操作延迟（插入、更新、查询时间）
  • 副本延迟（如果运行副本集）

建议： 为关键阈值配置警报，例如高磁盘使用率、连接激增或复制延迟超过五秒。

管理磁盘空间和存储增长

随着文档和索引的增长，MongoDB 数据库会动态扩展。如果不监控磁盘使用情况，数据库可能会因空间不足而锁定或崩溃。

检查磁盘使用情况

使用以下命令检查当前文件系统使用情况：

df -h /var/lib/mongodb

这显示了 MongoDB 数据目录的可用空间和已用空间。

你也可以通过 MongoDB 本身检查内存和缓存使用情况：

mongosh --eval "db.serverStatus().wiredTiger.cache"

当前缓存中的字节数 值表示 WiredTiger 存储引擎使用了多少内存。

设置磁盘使用提醒

为了保持主动性，设置警报或监控检查，当磁盘使用超过85%时通知你。例如，可以安排一个简单的脚本定期运行：

df -h | awk '$5 > 85 {print $0}'

您可以将其集成到 systemd 定时器或监控工具中以实现自动化。

管理旧数据和日志

大型或未使用的集合和日志文件随着时间的推移可能会占用大量空间。要管理日志，请在 /etc/logrotate.d/mongodb 中配置轮换（如本节后面所示）或手动清理：

sudo journalctl --vacuum-time=7d

sudo rm -f /var/log/mongodb/*.gz

对于应用程序数据，考虑为存储临时或时间敏感数据的集合使用TTL（生存时间）索引：

db.sessionLogs.createIndex({ "createdAt": 1 }, { expireAfterSeconds: 604800 })

这会自动删除七天前的文档。

安全升级操作

升级 MongoDB 需要仔细规划，尤其是在跨主要版本进行迁移时。以下流程可以将停机时间降到最低，并确保兼容性。

检查当前版本

确认已安装的版本：

mongod --version

升级前请备份

升级前务必创建完整备份：

mongodump --out /backups/mongodb/pre-upgrade-$(date +%F)

更新软件包仓库并升级

如果您之前固定了 MongoDB 软件包以防止自动更新，请取消这些固定：

echo "mongodb-org install" | sudo dpkg --set-selections

然后更新你的软件包列表并升级 MongoDB：

sudo apt update

sudo apt install -y mongodb-org

MongoDB 在升级过程中会保留您的配置和数据文件，但备份能确保在出现问题时可以回滚。

验证升级

升级后：

  1. 验证服务状态：

    sudo systemctl status mongod

  2. 检查最近的日志以查看警告或迁移说明：

    sudo tail -n 30 /var/log/mongodb/mongod.log

  3. 确认新版本：

    mongosh --eval "db.version()"

建议： 对于重大版本升级（例如，从 7.x 升级到 8.x），请务必阅读官方 MongoDB 发布说明。

某些查询行为或内部存储结构可能会发生变化。

自动化日常维护

手动维护适用于小型环境，但自动化可以确保一致性。您可以使用 cron 或 systemd 定时器 来安排定期备份、日志轮换或监控检查。

安排自动备份

编辑根用户的定时任务表：

sudo crontab -e

添加以下行以每天凌晨2点备份您的MongoDB实例：

0 2 * * * mongodump --out /backups/mongodb/$(date +\%F)

这会每天创建一个带日期的备份文件夹。

配置日志轮换

为了防止日志文件占用磁盘空间，请创建一个日志轮换配置文件：

sudo nano /etc/logrotate.d/mongodb

添加以下内容：

/var/log/mongodb/mongod.log {
    weekly
    rotate 5
    compress
    delaycompress
    missingok
    notifempty
    create 640 mongodb adm
    postrotate
        systemctl reload mongod > /dev/null 2>&1 || true
    endscript
}

此配置保留五周的日志，压缩较旧的文件，并在日志轮换后重新加载 MongoDB。

保持系统时间准确

MongoDB 的日志记录和复制功能依赖于准确的时间戳。如果系统时钟发生漂移，在崩溃后可能会出现复制延迟或日志损坏。

Ubuntu 24.04 默认使用 systemd-timesyncd，但你也可以使用 chrony 来实现更精确的时间同步：

sudo apt install chrony -y

sudo systemctl enable --now chrony

您可以通过以下方式验证同步：

timedatectl status

如果 NTP synchronized 显示为 yes，说明你的系统时钟已同步。

实时检查 MongoDB 健康状况

MongoDB 提供了 serverStatus 命令用于全面的运行时诊断。你可以直接在 shell 中查询它：

mongosh --eval "db.serverStatus()"

这将返回一个包含以下指标的详细 JSON 对象：

  • 内存消耗
  • 缓存使用
  • 连接数
  • 操作吞吐量
  • 复制状态

您可以提取特定字段以进行有针对性的检查。例如，要查看连接统计信息：

mongosh --eval "db.serverStatus().connections"

这可以快速了解系统是否正面临连接饱和或资源限制。

准备高可用性

单节点 MongoDB 部署适用于开发或低关键性应用。在生产环境中，你应当实施副本集。副本集提供冗余和自动故障转移，即使一个节点出现故障，也能保证可用性。

在典型的设置中：

  • 一个节点作为主节点，处理所有写操作和大部分读操作。
  • 一个或多个辅助节点实时复制数据。
  • 如果主节点离线，其中一个备用节点会自动成为新的主节点。

副本集还简化了备份和扩展等维护任务。你可以将备份或分析查询分担到辅助节点，而不会影响主节点的性能。

您的 MongoDB 实例现在已完全运行并得到妥善维护。

扩展与性能优化

MongoDB 的设计是为了水平扩展，这意味着您可以通过增加更多服务器来提高容量和性能，而不仅仅依赖于单一的、更强大的机器。随着数据集的增长或应用程序开始处理更多并发查询，扩展可以确保 MongoDB 持续可靠且高效地运行。

扩展 MongoDB 主要有两种方式：

  1. 副本集，通过冗余提高可靠性和读取性能。
  2. 分片，将数据分布到多个服务器上，以处理更大规模的数据集和写入负载。

理解副本集

副本集是一组 MongoDB 服务器，它们维护数据的相同副本。副本集提供高可用性，并能够防止硬件或网络故障。如果主节点发生故障，其中一个从节点会自动接管，确保停机时间最短。

一个标准副本集由以下部分组成：

  • 一个主要节点，负责处理所有写操作。
  • 两个或更多从节点 从主节点复制数据。
  • 可选裁决节点，参与选举但不存储数据。

对于生产系统，MongoDB 建议在副本集里至少有三个成员。

配置副本集

要创建副本集，你至少需要两到三个服务器（物理服务器或虚拟服务器）。每个节点都应安装并配置 MongoDB。

  1. 在每个节点上，打开配置文件 /etc/mongod.conf 并添加复制部分：

    replication:
  replSetName: "rs0"

  2. 在每台服务器上重启 MongoDB：

    sudo systemctl restart mongod

  3. 在主节点上，连接到 MongoDB 并初始化副本集：

    mongosh

    然后运行：

    rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "mongodb1.example.com:27017" },
    { _id: 1, host: "mongodb2.example.com:27017" },
    { _id: 2, host: "mongodb3.example.com:27017" }
  ]
})

  4. 验证状态：

    rs.status()

    输出应显示一个主节点和两个从节点，并将它们的状态标记为“PRIMARY”和“SECONDARY”。

副本集的好处

副本集提供几个重要的优势：

  • 高可用性： 如果主节点离线，自动故障转移可确保持续运行。
  • 数据冗余：每个节点都保留一份完整的数据副本。
  • 读取可扩展性：辅助节点可以处理读取操作，从而减轻主节点的负载。
  • 维护灵活性： 您可以在不影响可用性的情况下对辅助节点进行备份或系统更新。

最佳做法： 在不同的物理区域或可用性区域均匀分布副本节点，以防止在故障期间数据丢失。

理解分片

分片是 MongoDB 用于水平扩展的策略。当数据集变得过大，单台服务器无法高效存储或处理时，MongoDB 可以将其划分为更小的块，分布在称为分片的多台服务器上。

每个分片保存数据的一个子集，而整个集群则整体表现为一个逻辑数据库。

分片集群的组件

一个典型的 MongoDB 分片集群包括：

  • 分片：承载数据的节点，通常以副本集形式部署以实现冗余。
  • 配置服务器：存储元数据和集群配置，包括数据块分布。
  • Mongos 路由器：根据分片键将客户端查询路由到正确的分片。

选择分片键

分片键决定了 MongoDB 如何在分片之间分配数据。选择不当的分片键可能导致数据分布不均（称为数据倾斜）或热点问题。

好的分片键通常具有以下特征：

  • 高基数（许多唯一值）。
  • 甚至数据访问模式。
  • 一个可预测的查询模式，其中大多数查询都包含分片键。

为数据库启用分片的示例：

sh.enableSharding("salesdb")
sh.shardCollection("salesdb.orders", { "customer_id": 1 })

此命令在 salesdb 数据库上启用分片，并使用 customer_id 字段对 orders 集合进行分片。

何时使用分片

当出现以下情况时，你应该考虑分片：

  • 数据库接近或超过单个服务器的存储容量限制。
  • 写入吞吐量持续使 CPU 或磁盘 I/O 达到最大。
  • 工作集不再适合放入内存，导致频繁的页面交换。
  • 您预计您的数据集将呈指数增长。

分片会增加架构复杂性，因此最好只在必要时引入。

注意：在集合被分片之后，MongoDB 不支持取消分片。在启用分片之前，请仔细规划您的分片键。

优化 WiredTiger 性能

MongoDB 默认使用 WiredTiger 存储引擎。它针对现代硬件进行了优化，并使用压缩、缓存和多线程 I/O。了解 WiredTiger 如何管理内存和磁盘 I/O 有助于提高性能。

内存使用

WiredTiger 通常使用约 50% 的可用内存作为其缓存，MongoDB 会根据系统内存动态调整这一数值。

你可以在配置文件中调整这个设置：

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8

如果您的系统在运行 MongoDB 的同时还运行其他内存密集型服务，这会非常有用。对于专用的 MongoDB 服务器，通常最好保留默认的缓存设置。

您可以通过运行以下命令查看当前缓存使用情况：

mongosh --eval "db.serverStatus().wiredTiger.cache"

压缩

WiredTiger 支持数据和索引压缩以减少磁盘使用量。默认情况下，它使用 Snappy 压缩，在性能和空间效率之间取得平衡。如果您优先考虑节省磁盘空间而非速度，可以切换到 zlib（获得更好的压缩）或 zstd（适用于较新的系统）。

示例配置：

storage:
  wiredTiger:
    collectionConfig:
      blockCompressor: zstd

记录与耐用性

日志记录确保写操作是持久的，即使在断电情况下也是如此。您可以调整 commitIntervalMs 参数来控制日志写入的频率：

storage:
  journal:
    commitIntervalMs: 100

较低的间隔可以提高耐用性，但可能会略微降低写入性能。

建议： 对于大多数生产工作负载，请保留默认的日志记录设置，因为 WiredTiger 在性能与耐久性之间的平衡经过充分测试。

监控与扩展触发器

重要的是要识别何时需要扩展你的 MongoDB 部署。监控诸如 CPU 负载、内存使用情况和 I/O 等待时间等指标将有助于判断何时需要增加更多容量。

导致扩张的常见因素

  • CPU 使用率持续高于 80%.
  • 磁盘 I/O 延迟超过可接受阈值（例如，超过 10 毫秒）。
  • RAM 使用率在长时间内接近最大值。
  • 工作集大小快速增长。
  • 节点之间的复制延迟增加。

当出现这些指标时，可以考虑增加更多的副本（用于读取）或分片（用于写入密集型负载）。

纵向扩展 vs 横向扩展

垂直扩展涉及向现有服务器添加更多资源（CPU、内存、更快的磁盘）。管理起来更简单，但受硬件容量限制。

水平扩展涉及添加新服务器来分担工作负载。这是 MongoDB 的优势，因为在设计得当时，它几乎可以线性扩展。

迁移到托管 MongoDB

随着系统的增长，管理自托管集群可能会变得复杂。在这个阶段，迁移到托管的 MongoDB 服务，如 MongoDB Atlas，可以显著减少运营负担。

托管平台可以处理自动备份、补丁管理、监控、扩展和加密。然而，与自管理的设置相比，它们可能会增加额外成本，并且灵活性略低。

<$> 建议： 继续自托管，直到你的团队面临持续的运营挑战，例如性能瓶颈、集群管理的复杂性，或受管理平台更高效处理的合规要求。 <$>

比较：自托管 MongoDB 与托管 MongoDB

MongoDB 可以通过两种主要方式部署：

  1. 自托管，指你自己安装、配置并维护数据库（如本指南所述）。
  2. 托管，由第三方提供商为你托管和运营 MongoDB，作为一种服务提供。

每种方法都有其独特的优势和权衡。正确的选择取决于您的技术专长、工作负载特性、合规需求以及运营优先级。

让我们深入分析这两个选项。

自托管 MongoDB

当你自托管 MongoDB 时，你会将其直接安装在自己的基础设施上，无论是物理服务器、虚拟机，还是像 Linux-Console.net Droplet 这样的云实例。你可以控制环境的每一个方面，从安装到升级再到监控。

自托管的优势

  1. 完全控制与灵活性：您可以完全掌控配置设置、文件系统、网络以及性能调优。您可以修改mongod.conf文件，选择存储路径，并应用符合您组织标准的自定义安全或备份策略。
  2. 小规模部署的成本效益：对于小型或中型工作负载，自行托管可能比使用托管服务更便宜。您只需为基础的计算和存储资源付费，而不需要额外的管理层费用。
  3. 自定义安全策略：您可以将 MongoDB 与内部 VPN、防火墙或私有网络集成，确保完全符合本地或特定行业的安全要求。一些组织由于数据存放地或法规限制，需要在本地部署，这使得自托管成为唯一可行的选项。
  4. 性能优化：由于您可以控制硬件，您可以微调系统参数，如I/O调度程序、缓存大小和压缩算法。您还可以将MongoDB与相关服务部署在同一位置，以最小化网络延迟。

自托管的挑战

  • 运营开销：您需要负责管理所有事务；从安装更新和补丁到处理故障和性能调优。这需要拥有数据库管理和Linux系统管理专业知识的专职人员。
  • 可扩展性复杂性：扩展自托管的 MongoDB 集群意味着需要手动配置新服务器、重新平衡数据、更新配置以及维护复制或分片拓扑。没有自动化，这些任务容易出错。
  • 备份与灾难恢复：您必须设计、测试并维护自己的备份、恢复和异地存储流程。虽然 MongoDB 的工具（mongodump、mongorestore 和卷快照）可以实现这一点，但这需要有条不紊的操作规划。
  • 监控与警报：自托管 MongoDB 需要您使用 Prometheus、Grafana 或 Percona PMM 等工具来设置监控和警报系统。如果没有持续的可视化，故障或性能瓶颈可能会被忽视，直到导致系统停机。

总之，自行托管的 MongoDB 在小规模下提供灵活性、独立性和较低成本，但需要大量持续的维护工作。

托管 MongoDB 服务

托管的 MongoDB 服务会代表您托管数据库，自动处理所有基础设施、更新、扩展和安全补丁。这些服务消除了大部分管理开销，同时提供高可用性和全球可扩展性。

托管 MongoDB 的优势

  1. 最小化操作工作量：服务提供商会自动处理数据库的供应、备份、升级和故障切换。您只需点击几次或通过 API 调用即可部署新集群，从而大幅减少管理工作量。
  2. 自动扩展：托管服务可以随着数据集的增长动态调整计算和存储资源。例如，MongoDB Atlas 支持自动分片和垂直扩展，无需停机。
  3. 内置监控和警报：托管平台包括用于 CPU 使用率、磁盘性能、连接统计和查询延迟的仪表板。您可以为关键指标设置警报阈值，而无需部署额外的监控工具。
  4. 默认高可用：大多数托管服务会在不同的可用区部署包含三个或更多副本集节点的集群。这确保了自动故障切换和高正常运行时间，且配置最少。
  5. 安全与合规：托管的 MongoDB 平台提供内置加密、基于角色的访问、网络隔离（VPC 对等连接）以及与身份提供者的集成。它们还通过了 SOC 2、GDPR、HIPAA 和 ISO 27001 等标准认证，从而简化了合规审计。
  6. 全球分布：MongoDB Atlas 和类似服务支持多区域集群。数据可以在靠近用户的地理位置进行复制，从而改善分布式应用的延迟。

托管服务的局限性

  1. 大规模成本更高：托管服务因自动化和便利性而收取额外费用。随着数据量和流量的增长，每月成本可能超过运行自托管实例的费用，尤其是对于存储在 SSD 上的大型数据集。
  2. 有限的自定义：托管环境限制对低级配置选项的访问。您无法修改文件系统级别的设置、缓存调优或底层操作系统参数。
  3. 供应商锁定：每个提供商都有独特的 API 和部署配置，这使得以后在服务之间迁移变得困难。
  4. 网络依赖性：托管数据库依赖外部网络连接。如果您的应用程序在本地环境中运行，安全连接到托管服务可能会引入延迟或依赖 VPN 隧道。

总之，托管的 MongoDB 服务大大减少了管理负担并提高了可靠性，但代价是灵活性下降和经常性费用增加。

功能对比表

功能自托管 MongoDB托管的 MongoDB（例如 Atlas）
设置工作量手动安装和配置一键或自动配置
配置控制完全控制系统和存储设置有限；提供者管理内部事务
性能优化可自定义（硬件和操作系统级别）由提供商预优化
可扩展性手动；手动添加分片或副本自动纵向和横向扩展
高可用性必须配置副本集默认启用
备份使用 mongodump 或快照的手册支持保留选项的自动化
监控外部工具（Prometheus、PMM、Grafana）集成仪表板和警报
安全与合规完全可定制；用户自负托管加密、基于角色的访问控制、认证
运营开销高；需要有经验的数据库管理员低；由提供方处理
成本（长期）适合小型配置的更低更高，尤其是在大规模上
理想使用情况小型团队、开发、受监管的环境大规模分布式或云原生应用

选择合适的部署模型

在自托管和托管 MongoDB 之间做出决定，主要取决于贵组织的优先事项、资源和限制。请考虑以下情况：

  • 如果选择自托管 MongoDB：

    • 您需要对基础设施和数据拥有完全控制权。
    • 你的工作量适中且可预测。
    • 你在 Linux 和 MongoDB 管理方面拥有内部专业知识。
    • 合规性或数据驻留法律要求本地存储。

  • 如果符合以下情况，请选择托管 MongoDB：

    • 您更喜欢专注于应用程序开发而不是基础设施。
    • 您需要具有最少设置的自动扩展和高可用性。
    • 你们的团队缺乏专职数据库管理员。
    • 您需要全球分布的集群或符合合规认证（SOC 2、HIPAA、GDPR）。

实用建议： 许多组织采用混合方法：他们在测试、预发布或区域性工作负载中使用自托管 MongoDB，而在需要高可用性和可扩展性的生产系统中使用托管 MongoDB（Atlas）。

故障排除与维护

即使在最仔细的配置和监控下，MongoDB 部署中仍可能出现问题。这些问题可能包括性能缓慢、启动失败、复制延迟或磁盘空间耗尽。保持 MongoDB 环境稳定的关键是有一个结构化的方法来诊断问题并执行预防性维护操作。

检查 MongoDB 服务状态

排查 MongoDB 问题的第一步是确认数据库服务是否正常运行。

您可以使用以下命令检查当前状态：

sudo systemctl status mongod

如果 MongoDB 正在运行，你应该会看到包括以下内容的输出：

Active: active (running)

Main PID: 3564 (mongod)

如果服务是未激活、失败或停止状态，请重启它：

sudo systemctl restart mongod

重启后，再次检查其状态。如果立即失败，请查看日志文件以获取具体错误信息。

查看 MongoDB 日志

日志是诊断信息的最直接来源。MongoDB 会在其主日志文件中记录所有主要事件、警告和错误，位置如下：

/var/log/mongodb/mongod.log

要查看最新条目，请运行：

sudo tail -n 30 /var/log/mongodb/mongod.log

如果 MongoDB 无法启动，您通常会看到以下错误之一：

  • 权限被拒：/var/lib/mongodb 或 /var/log/mongodb 的所有权或权限不正确。请检查权限并修复它们：

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

  • 未找到数据目录：请确保 /var/lib/mongodb 存在，并且与 /etc/mongod.conf 中定义的路径一致。

  • 地址已被使用：另一个进程正在使用端口 27017。可以通过以下方式识别它：

    sudo lsof -i :27017

    并停止或重新配置有冲突的服务。

  • 损坏的数据文件： 如果 MongoDB 被异常关闭，可能会发生这种情况。在这种情况下，日志应该会在重启时自动恢复数据。如果恢复失败，您可能需要从备份中恢复数据。

提示：在调试期间进行连续日志检查时，请使用：

sudo tail -f /var/log/mongodb/mongod.log

诊断连接问题

连接问题是另一个常见问题。当客户端无法连接到 MongoDB 时，通常是由于网络、身份验证或配置问题导致的。

验证 MongoDB 是否在正确的接口上监听

运行：

sudo ss -tulpn | grep mongod

输出应显示 MongoDB 绑定到 127.0.0.1（用于本地连接）以及任何已配置的外部 IP。如果 MongoDB 没有监听预期的 IP，请检查 /etc/mongod.conf 中的 bindIp 字段：

net:
  bindIp: 127.0.0.1,192.168.10.50

编辑后重启 MongoDB：

sudo systemctl restart mongod

检查防火墙规则

如果远程连接失败，请确认防火墙允许 27017 端口的流量：

sudo ufw status

如果没有，请允许来自特定 IP 的连接：

sudo ufw allow from 192.168.10.50 to any port 27017

使用 Telnet 或 Ping 测试连接性

从客户端系统测试端口是否可到达：

telnet mongodb-server-ip 27017

或者

nc -vz mongodb-server-ip 27017

如果连接成功，问题可能与身份验证或用户权限有关。

排查身份验证失败问题

在启用访问控制或更改用户凭据后，经常会发生身份验证问题。

确认已启用身份验证

本地连接并验证：

mongosh --eval "db.runCommand({ getParameter: 1, authenticationMechanisms: 1 })"

如果输出中包含 "SCRAM-SHA-256"，则表示身份验证已启用。

验证登录凭证

尝试使用管理员账户连接：

mongosh -u admin -p --authenticationDatabase admin

如果这失败，从本地连接且无需身份验证（仅当没有用户存在时可从本地主机进行），然后重新创建管理员账户：

use admin

db.createUser({
  user: "admin",
  pwd: "NewStrongPassword",
  roles: ["userAdminAnyDatabase", "readWriteAnyDatabase"]
})

检查数据库上下文

每个 MongoDB 用户都在特定的数据库中定义。如果你在错误的数据库进行身份验证，身份验证将会失败。例如，如果用户是在 admin 数据库中创建的，你必须明确地在该数据库进行身份验证：

mongosh -u admin -p --authenticationDatabase admin

解决性能问题

性能下降可能由高内存使用、磁盘I/O缓慢、未优化的查询或过多的并发连接引起。MongoDB 提供了多种诊断工具来识别这些问题。

检查资源使用情况

使用 Linux 命令检查系统级别的指标：

top

vmstat 2

iostat -x 2

检查 mongod 的高 CPU 使用情况或磁盘延迟是否超过 10 毫秒。

监控数据库操作

运行：

mongostat 2

此显示实时指标，包括每秒的插入、查询、更新和删除操作。

如果某些操作显得缓慢，请使用MongoDB 性能分析器来识别运行时间较长的查询。

启用查询分析

您可以暂时启用分析器来记录慢查询：

use myappdb

db.setProfilingLevel(1, { slowms: 100 })

这会记录任何执行时间超过100毫秒的查询。

查看结果：

db.system.profile.find().sort({ ts: -1 }).limit(5).pretty()

建议：在生产环境中，如果不进行故障排查，请保持禁用分析功能，以避免性能开销。

分析索引效率

低效的查询通常源于缺失索引。要查看 MongoDB 是否正确使用索引，可以在查询前加上 explain()：

db.orders.find({ customer_id: 12345 }).explain("executionStats")

如果 executionStages.stage 显示 "COLLSCAN"，说明 MongoDB 正在执行全表扫描。你可以创建索引来提高性能：

db.orders.createIndex({ customer_id: 1 })

修复损坏的数据库

数据损坏很少发生，但可能由于断电或磁盘错误而出现。如果 MongoDB 无法启动并且日志显示 WiredTiger 文件损坏，请按照以下步骤操作：

  1. 停止 MongoDB：

    sudo systemctl stop mongod

  2. 备份当前数据目录：

    sudo cp -r /var/lib/mongodb /var/lib/mongodb-corrupt-backup

  3. 尝试进行修复操作：

    sudo -u mongodb mongod --repair --config /etc/mongod.conf

  4. 重启 MongoDB：

    sudo systemctl start mongod

如果修复失败，请从您最近的备份中恢复数据。

例行维护任务

预防性维护可以大大降低意外故障的可能性。

定期更换日志

确保您的日志轮换策略处于启用状态。MongoDB 支持内部日志轮换（logRotate 命令）以及在启用 logAppend 时通过 logrotate 进行外部轮换。若日志增长过快，您可以手动触发它：

sudo logrotate -f /etc/logrotate.d/mongodb

紧凑集合

集合在经过多次插入和删除后可能会变得碎片化。compact 可以回收空间，但这是一个阻塞操作，应该很少在生产环境中使用。WiredTiger 会自动处理大部分碎片，因此通常不需要进行压缩操作。

请注意，此操作会锁定数据库，因此请在低流量时段进行。

验证集合

定期进行数据完整性检查：

db.runCommand({ validate: "collection_name" })

这可以验证索引和文档是否一致。

监控磁盘和内存使用情况

使用自动警报在磁盘使用率超过85%或内存利用率达到关键水平时发出警告。像 Prometheus、Percona PMM 或 MongoDB Atlas Monitor 这样的监控工具可以随时间跟踪这些指标。

安全地应用系统更新

在更新 MongoDB 或底层 Ubuntu 系统时，请始终遵循结构化的流程：

  1. 请先备份您的数据。

  2. 在进行内核或库升级之前，请停止 MongoDB 服务：

    sudo systemctl stop mongod

  3. 应用更新：

    sudo apt update && sudo apt upgrade -y

  4. 重新启动服务并确认其正常运行：

    sudo systemctl start mongod

sudo systemctl status mongod

注意：切勿在写入操作或日志活动期间中断 MongoDB，否则可能会导致数据损坏。

主动维护工具

有几种工具可以简化日常维护和健康检查：

  • MongoDB Compass：用于可视化浏览数据和性能指标的图形界面工具。
  • Atlas CLI：用于管理 MongoDB Atlas 上的集群、用户和备份。
  • Mongosh 脚本：自定义脚本可以自动执行健康检查或生成连接数和磁盘使用情况的每日报告。
  • Ansible 剧本：自动化安装、配置验证和备份计划。

灾难恢复测试

维护计划的最后一步是测试恢复程序。备份只有在能正确恢复时才有用。

每季度至少一次：

  1. 将您最近的备份恢复到临时服务器。
  2. 验证索引、用户和权限是否正确加载。
  3. 测量恢复时间以确保其满足您的恢复时间目标 (RTO)。
  4. 记录该过程，以便任何管理员在紧急情况下都能执行。

长期维护清单

任务频率目的
验证备份每日确认备份已完成并可恢复
检查复制和日志每日检测延迟或节点同步问题
监控磁盘和内存使用情况每日防止容量耗尽
查看慢查询日志每周识别性能瓶颈
应用操作系统和 MongoDB 更新每月保持软件安全和最新
测试恢复程序季度验证灾难恢复准备情况
审查用户访问季度保持最低权限安全

通过遵循这些故障排除和维护方法，您可以在 Ubuntu 上保持一个健康的 MongoDB 部署，使其长期保持高性能、安全和可靠。持续的监控和维护的成本远低于从停机或数据丢失事件中恢复的成本。

常见问题

1. 为什么 MongoDB 在默认的 Ubuntu 软件库中不可用？

由于许可变更，MongoDB 在 Ubuntu 18.04 版本之后被从默认软件仓库中移除。MongoDB 服务器端公共许可证（SSPL）未被 Debian 和 Ubuntu 项目认可为开源许可证。因此，Canonical 不再在其官方仓库中分发 MongoDB，用户必须从 MongoDB 自己的 APT 仓库进行安装。

2. 我如何完全卸载 MongoDB？

要卸载 MongoDB 并删除所有相关文件，请运行以下命令：

sudo systemctl stop mongod

sudo apt purge -y mongodb-org*

sudo rm -rf /var/lib/mongodb

sudo rm -rf /var/log/mongodb

sudo rm -f /etc/apt/sources.list.d/mongodb-org-*.list

sudo apt autoremove -y

这会停止 MongoDB 服务，移除所有相关的软件包，删除数据和日志目录，并清理仓库条目。

3. 我如何检查 MongoDB 是否正在运行？

你可以使用以下命令检查 MongoDB 服务的状态：

sudo systemctl status mongod

如果 MongoDB 正在运行，你会看到一行显示 “Active: active (running)”。或者，你可以通过运行以下命令来确认连接性：

mongosh --eval "db.runCommand({ connectionStatus: 1 })"

如果命令返回 "ok": 1，则 MongoDB 正在运行并接受连接。

4. MongoDB 可以在小型 VPS 上运行吗？

是的，MongoDB 可以在小型 VPS 上运行，但有一些限制。对于基本的开发或测试工作负载，配备 2 个 CPU 核心、2 GB 内存和 10–20 GB SSD 存储的服务器就足够了。

然而，对于生产环境使用，MongoDB 在至少配备 4 个 CPU 核心、8 GB 内存以及高速 SSD 或 NVMe 存储的系统上性能最佳。内存较低的环境可能需要调整 WiredTiger 缓存大小以防止过度交换。

5. 为什么在运行修复操作后 MongoDB 无法启动？

如果以 root 用户运行修复过程，MongoDB 在修复后可能无法启动，因为这会将 /var/lib/mongodb 中的数据文件所有权更改为 root:root。由于 mongod 服务以 mongodb 用户身份运行，因此没有权限读取或写入这些文件。为了解决此问题，请确保以 mongodb 用户运行修复命令，或者随后恢复正确的所有权：

sudo chown -R mongodb:mongodb /var/lib/mongodb

6. 我如何判断 MongoDB 是否在正确的网络接口上监听？

您可以使用以下方式验证 MongoDB 的活动监听器：

sudo ss -tulpn | grep mongod

这显示了 MongoDB 绑定的 IP 地址和端口。如果你没有看到预期的 IP（例如，你的应用服务器的 IP），请检查 /etc/mongod.conf 中的 bindIp 值，然后重新启动服务。

7. 我应该更改 MongoDB 默认的 WiredTiger 缓存大小吗？

在大多数情况下，不需要。WiredTiger 会自动使用大约 50% 的系统内存，并根据可用内存动态调整缓存使用。只有在 MongoDB 与其他占用大量内存的应用程序共享服务器时，才需要调整 cacheSizeGB 设置。专用的 MongoDB 服务器通常应保持默认行为。

8. 为什么我的 MongoDB 日志会变得这么大？

MongoDB 会不断地将操作数据写入其日志文件 /var/log/mongodb/mongod.log。如果没有进行日志轮转，该文件可能会变得非常大。请确保按照指南维护部分的说明使用 logrotate 配置日志轮转，以便旧日志能够自动压缩或删除。

9. 我什么时候应该考虑向我的副本集添加更多节点？

当你注意到读流量持续增加、节点频繁选举、复制延迟，或者需要在多个可用区或地区提高可用性时，应该扩展你的副本集。增加副本节点可以分担读取负载并提高容错能力，尤其适用于生产环境。

10. 我如何确认 TLS 在我的 MongoDB 服务器上已正确启用？

在 /etc/mongod.conf 中配置 TLS 后，使用以下方式连接：

mongosh --tls --host <server-ip> -u admin -p --authenticationDatabase admin

如果连接成功，运行：

openssl s_client -connect <server-ip>:27017

有效的 TLS 握手以及诸如 Protocol: TLSv1.3 的详细信息确认加密已激活。

结论

有效运行 MongoDB 不仅仅是安装和设置；还需要在性能、安全性和可靠性之间保持平衡。现在，你已经拥有一个功能齐全的 MongoDB 系统，可以支持生产工作负载，随着需求扩展，并从意外故障中恢复。

通过应用本指南中概述的原则和最佳实践，从日常监控到长期容量规划，您可以在任何环境中自信地操作 MongoDB。无论您是继续自行管理，还是迁移到像 MongoDB Atlas 这样的托管服务，您对 MongoDB 内部工作原理的理解都能确保您始终掌控自己的数据。

要了解更多关于数据库的信息，请查看以下教程：

  • 数据库的不同类型有哪些？附使用案例和架构解析
  • SQLite 与 MySQL 与 PostgreSQL：关系型数据库管理系统比较
  • 如何在 Ubuntu 上安装 Node.js
  • 如何入门 MERN 技术栈

感谢您与 Linux-Console.net 社区一起学习。