📚 课程目录第3章 MongoDB版本与安装包选择

3. MongoDB版本与安装包选择

副本集高可用的稳定性，从选对版本和安装包那一刻就已经决定了一半。生产环境里最常见的两类事故——升级后副本集无法选主、备份恢复时发现缺少企业级加密能力——往往不是运维操作失误，而是版本与发行版选型阶段埋下的隐患。本节围绕三个决策点展开：选社区版还是企业版、选哪个版本号、以及如何用统一的目录与安装流程把节点做成可复制的标准件。

社区版与企业版：能力边界与选型判断

MongoDB 官方发行版分为 Community（社区版）与 Enterprise（企业版），二者共享同一套存储引擎、复制协议与查询语言，副本集的基本行为完全一致。差异集中在安全、运维与支持三个维度。

能力维度	社区版 Community	企业版 Enterprise
许可与费用	SSPL，免费	商业订阅，按节点/年计费
传输与静态加密	仅支持 TLS 传输加密	TLS + 静态加密（WiredTiger 加密存储引擎）
审计	无	支持审计日志，可输出到文件或 syslog
身份认证	SCRAM、x.509	额外支持 LDAP、Kerberos 外部认证
内存存储引擎	无	In-Memory 引擎
运维工具	mongodump/mongorestore、mongostat	Ops Manager、Cloud Manager、BI Connector
官方支持	社区论坛	SLA 技术支持、热补丁

选型判断可以归结为几个硬性条件：如果业务涉及金融、医疗等合规审计要求，或数据必须落盘加密，企业版几乎是必选项；如果使用 LDAP/Kerberos 统一身份体系，也只有企业版能满足。反之，若团队已有成熟的 TLS 证书体系、数据敏感度可控、且具备自建监控能力（如 Prometheus + mongodb_exporter），社区版完全可以支撑高可用副本集。需要提醒的是，社区版从 4.4 起已内置免费监控命令 db.serverStatus() 与 mongostat，配合外部采集足以覆盖副本集健康度观测。

不要为了“以后可能用到”而采购企业版。企业版的静态加密会带来密钥管理（KMIP）的额外运维成本，若没有对应的密钥基础设施，反而增加故障面。

版本号选择：稳定版、次版本与生命周期

MongoDB 采用 主版本.次版本.补丁版本 三段式命名，例如 7.0.14。其中次版本为偶数的是稳定版（如 6.0、7.0），奇数的是开发版（如 6.1、7.1），生产环境只应选择偶数稳定版。补丁版本用于修复缺陷与安全问题，应选择当前稳定分支中较新的补丁号。

选版本时还要看官方生命周期表。以 2024 年前后的常见选择为例：4.4 已进入 EOL，不再接收安全补丁；5.0 处于维护末期；6.0 与 7.0 是主流生产选择。副本集所有节点必须运行同一主版本，跨主版本滚动升级时，官方要求先升级到当前主版本的最新补丁，再逐节点升级到目标主版本，且不能跳版本（如 5.0 不能直接升到 7.0，需经 6.0）。

另一个容易被忽略的点是 Feature Compatibility Version（FCV）。升级二进制后，FCV 仍停留在旧版本，直到执行 db.adminCommand({setFeatureCompatibilityVersion: "7.0"}) 才启用新特性。这个设计给了回退窗口，但也意味着“升级完成”不等于“新特性可用”，需要显式确认。

标准化安装流程与目录规划

生产部署不应依赖系统包管理器安装的 mongod，因为其数据目录、日志路径和配置文件位置由发行版决定，不利于多节点统一。推荐使用官方 tarball 手动部署，把每个节点做成结构一致的标准件。

# 以 mongodb 7.0.14 为例，三节点副本集统一目录规划
/opt/mongodb/
├── bin/                 # mongod, mongos, mongosh 等二进制
├── conf/
│   └── mongod.conf      # 节点配置，各节点仅差异 bindIp 与端口
├── data/                # dbPath，建议独立数据盘挂载
├── log/
│   └── mongod.log       # 日志，配合 logRotate
└── keyfile/
    └── mongodb.key      # 副本集内部认证密钥，权限 400

# 安装步骤（每个节点执行）
tar -zxvf mongodb-linux-x86_64-enterprise-rhel80-7.0.14.tgz -C /opt/
mv /opt/mongodb-linux-x86_64-*-7.0.14 /opt/mongodb
useradd -r -s /sbin/nologin mongod
chown -R mongod:mongod /opt/mongodb
chmod 400 /opt/mongodb/keyfile/mongodb.key

配置文件建议显式写出关键参数，避免依赖默认值：

storage:
  dbPath: /opt/mongodb/data
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8          # 约为物理内存的 50%，留出系统与连接开销
systemLog:
  destination: file
  path: /opt/mongodb/log/mongod.log
  logAppend: true
net:
  port: 27017
  bindIp: 10.0.1.11           # 仅监听内网地址，不暴露公网
replication:
  replSetName: rs0
security:
  keyFile: /opt/mongodb/keyfile/mongodb.key
  authorization: enabled

目录规划的核心原则是“数据、日志、配置、密钥四分离”。dbPath 放在独立数据盘上，便于做快照备份与 IO 隔离；日志单独目录并配置 logRotate，防止磁盘被写满；keyFile 权限必须为 400 且属主为 mongod，否则 mongod 会拒绝启动。cacheSizeGB 需要按节点实际内存计算，例如 16GB 内存的节点设为 8，若与其它服务混部则要下调。

安装后的验证与常见坑

节点启动后不要急于初始化副本集，先做三项检查。第一，确认进程监听地址正确：ss -lntp | grep 27017 应只显示内网 IP，若出现 0.0.0.0 说明 bindIp 未生效。第二，确认日志无告警：grep -i "warning\|error" /opt/mongodb/log/mongod.log，重点关注 keyFile 权限与 dbPath 属主问题。第三，用 mongosh --port 27017 连接后执行 db.serverStatus().version，确认实际运行版本与安装包一致。

三个节点的 keyFile 内容必须完全相同，否则副本集内部认证会失败，表现为节点间心跳正常但无法完成选举。keyFile 建议用 openssl rand -base64 756 生成，长度 6~1024 字符。

最后，把上述流程固化为可复用的部署脚本或配置管理模板（Ansible role、Salt state 均可），让每个节点的差异只体现在 bindIp 与端口两个变量上。这样做的价值在扩容和故障重建时最明显：新增一个节点只需改两个参数，而不是重新回忆一遍安装细节。版本与安装包的选型一旦确定，就应在整个副本集生命周期内保持一致，升级时严格遵循“先补丁、后主版本、逐节点、最后改 FCV”的顺序。