CentOS 上 MongoDB 版本兼容性处理指南
一、先明确兼容性的关键维度
- 操作系统与 CPU 架构：选择与 CentOS 版本/内核 和 x86_64/s390x 一致的官方构建包，避免因平台不匹配导致库依赖或启动失败。
- 大版本与小版本：大版本之间常有特性与行为差异，升级通常需逐级进行，不可跨多个大版本直接升级。
- 特性兼容性版本 FCV：通过 featureCompatibilityVersion 控制新特性是否启用，升级前后需在合适时机调整 FCV。
- 驱动与 Shell：驱动需与目标 MongoDB 服务器版本匹配；注意 MongoDB 6.0 起不再内置 mongo shell，需使用 mongosh。
- 复制集/分片拓扑：跨大版本升级多为滚动升级，会触发多次重启与短暂闪断，需评估对应用的影响。
二、在 CentOS 7 上的版本选择与降级路径
- 若运行在 CentOS 7.9 且遇到 MongoDB 5.0.x 不兼容的情况，优先选择 MongoDB 4.4.x LTS 系列，这是官方与社区在 CentOS 7 上的稳定组合。
- 如必须使用 5.x，建议升级至 CentOS 8/Stream 9 或使用容器/云实例获取更好的官方支持。
- 版本选择建议表：
- CentOS 7.9：4.4.x（推荐）；5.0.x（不推荐/可能不兼容）
- CentOS 8/Stream 9：5.x/6.x/7.x（按官方支持矩阵选择）
- 降级原则：大版本升级后通常不支持降级；若已升级到不兼容版本，建议通过逻辑/物理备份恢复至低版本自建实例来“回滚”。
三、安全升级步骤（适用于 CentOS 7 自建环境）
- 步骤 0 兼容性评估
- 核对驱动、ORM/ODM、聚合管道、索引类型、认证机制等在目标版本的变化；在副本集/分片上先在测试环境演练。
- 步骤 1 备份与检查
- 全量备份（如 mongodump/物理备份），校验备份可用；记录当前 FCV：
- use admin
- db.adminCommand({getParameter: 1, featureCompatibilityVersion: 1})
- 步骤 2 逐级升级（示例：4.2 → 4.4 → 5.0）
- 正常关闭实例：db.shutdownServer()
- 替换二进制（或 RPM 升级），保持 dbPath/journal 配置不变
- 启动后升级 FCV：db.adminCommand({setFeatureCompatibilityVersion: “4.4”})，确认应用与索引可用
- 重复上述流程升级到 5.0
- 步骤 3 客户端与工具
- 升级驱动到与服务器匹配的版本；MongoDB 6.0+ 使用 mongosh 替代已移除的 mongo shell。
- 步骤 4 回滚预案
- 大版本升级后不支持直接降级；如需回滚，使用备份在目标低版本重建实例并恢复数据。
四、常见兼容性问题与修复要点
- FCV 未对齐导致升级失败或特性不可用
- 现象：升级命令报错或新特性未生效
- 处理：在升级前后按阶段设置 FCV（如 4.2 → 4.4 → 5.0），确保升级完成后再开启新特性。
- 默认 writeConcern 变化引发写入延迟
- 现象：从 4.4 → 5.0 写入延迟上升
- 处理：评估应用对 {w: majority} 的容忍度，必要时在连接字符串或代码中显式设置 writeConcern 与 timeout。
- 驱动/Shell 不匹配
- 现象：认证失败、命令不存在、API 不兼容
- 处理：驱动与服务器版本保持同主版本或官方支持矩阵；6.0+ 使用 mongosh。
- 系统平台不兼容
- 现象：安装包依赖冲突、启动失败
- 处理：在 CentOS 7.9 优先选择 4.4.x；若需 5.x+，迁移至 CentOS 8/Stream 9 或使用容器化方案。
五、上线前验证与运维建议
- 建立与生产一致的伪生产/克隆环境，用真实数据做回归测试，覆盖连接池、重试、超时、聚合、索引、事务等关键路径。
- 在副本集/分片上执行滚动升级演练，观察主备切换、升级闪断窗口与监控告警；应用侧使用 ConnectionStringURI 并具备自动重连能力。
- 升级窗口选择业务低峰期，并提前准备回滚方案（备份恢复/重建实例）。
