3. 版本兼容性矩阵与升级路径规划
MongoDB 的版本升级从来不是“把二进制换掉再重启”这么简单。真正决定升级能否平稳落地的，是三条相互咬合的约束：服务端版本特性差异、官方驱动与数据库的兼容性，以及FCV（Feature Compatibility Version，特性兼容版本）。理解这三者的关系，才能规划出一条既安全又可控的升级路径。
一、版本特性差异：为什么不能一步跨太多
MongoDB 采用“快速发布 + 稳定主线”的节奏。以 4.4、5.0、6.0、7.0 这条主线为例，每个大版本都会引入新的存储引擎行为、默认参数和废弃项。例如 5.0 引入了时序集合与在线重新分片，6.0 强化了分片均衡与加密查询，7.0 则对副本集成员状态和写入关注语义做了调整。这些变化意味着：跨大版本升级时，中间版本的元数据格式、默认配置和废弃命令必须被逐级消化。
官方给出的升级规则是：相邻大版本可以逐级升级，但不能跳级。也就是说，从 4.4 升到 6.0，必须先升到 5.0，再升到 6.0。原因在于每个大版本都会在启动时对数据文件做一次“升级检查”，跳级会导致旧版本无法识别的元数据被新版本直接拒绝，或者更糟——被静默忽略后留下隐患。
二、驱动兼容性：客户端不能掉队
服务端升级时，最容易出问题的往往不是数据库本身，而是应用侧的驱动。MongoDB 官方驱动遵循“向后兼容一个服务端大版本”的原则：例如 5.x 驱动可以连接 4.4 和 5.0，但连接 6.0 时可能缺少对新特性的支持，甚至在某些命令上出现协议不匹配。
因此升级前必须核对驱动版本矩阵。以 Node.js 驱动为例，4.x 驱动支持到 MongoDB 5.0，5.x 驱动才正式支持 6.0。如果应用仍在使用 3.x 驱动，那么升级服务端之前，必须先升级驱动并完成回归测试。驱动升级通常比服务端升级更早进行，因为它可以独立部署，且能提前暴露兼容性问题。
三、FCV：控制新特性何时生效
FCV 是 MongoDB 中一个非常关键但常被忽视的参数。它决定了当前副本集或分片集群“以哪个版本的语义运行”。即使二进制已经升级到 6.0，只要 FCV 仍设置为 5.0，数据库就会继续使用 5.0 的行为模式，新版本特性不会启用，旧版本驱动也能继续连接。
FCV 的设置遵循“先升级二进制，再提升 FCV”的顺序。具体来说：
- 将副本集所有成员的二进制升级到目标版本，并重启。
- 确认所有成员状态正常、复制延迟归零。
- 在主节点上执行
db.adminCommand({ setFeatureCompatibilityVersion: "6.0" })。 - 验证 FCV 已生效：
db.adminCommand({ getFeatureCompatibilityVersion: 1 })。
FCV 提升是不可逆的——一旦升到 6.0，就无法再降回 5.0。因此这一步必须在确认所有应用和驱动都已适配之后才执行。
四、升级路径规划：从矩阵到执行顺序
把上述三条约束放在一起，就能形成一张清晰的升级路径图。下面这张 SVG 展示了从 4.4 到 6.0 的典型升级路径，包括驱动升级、二进制升级、FCV 提升和验证节点的先后关系。
这张图的核心逻辑是：驱动升级先行，二进制升级逐级推进，FCV 最后提升。每个阶段之间都插入验证节点，确保问题在最小范围内暴露。对于分片集群，还需要额外考虑 mongos、config server 和 shard 的升级顺序——通常先升 config server，再升 shard，最后升 mongos，且每个组件内部同样遵循“先二进制、后 FCV”的原则。
五、跨版本升级的常见陷阱
在实际工程中，有几个高频问题值得提前规避。第一，忽略废弃命令：例如 5.0 废弃了 db.collection.ensureIndex()，如果应用仍在调用，升级后会直接报错。第二，FCV 提升过早：在驱动尚未适配时提升 FCV，会导致旧驱动连接失败。第三，副本集成员版本不一致：在滚动升级过程中，如果某个成员长时间停留在旧版本，可能触发选举异常。第四，忽略 oplog 大小：大版本升级后写入模式可能变化，oplog 增长过快会导致复制中断。
setFeatureCompatibilityVersion 之前，务必确认所有应用、驱动、备份工具和监控系统都已兼容目标版本。一旦提升，回退的唯一方式是恢复到升级前的备份。六、升级路径规划检查表
综合以上内容，可以整理出一份可直接使用的升级路径规划检查表。它覆盖了从准备到收尾的完整闭环，适合在变更评审时逐项确认。
| 阶段 | 检查项 | 判断依据 |
|---|---|---|
| 准备 | 驱动版本是否支持目标服务端 | 官方驱动兼容性矩阵 |
| 准备 | 废弃命令与配置是否已清理 | 升级日志与启动告警 |
| 二进制升级 | 逐成员替换，主节点最后 | rs.status() 成员状态 |
| 二进制升级 | 复制延迟是否归零 | rs.printSlaveReplicationInfo() |
| FCV 提升 | 所有成员版本一致 | db.version() 逐节点确认 |
| FCV 提升 | 应用回归测试通过 | 读写、聚合、事务用例 |
| 收尾 | 监控与备份工具适配 | 备份恢复演练 |
升级路径规划的本质，是把“版本差异”这个静态矩阵，转化为“驱动→二进制→FCV→验证”的动态执行序列。只要每一步都有明确的判断依据和回退预案，跨版本升级就可以从高风险操作变成可重复、可验证的工程流程。