MongoDB 3.6到4.2版本升级实战：分阶段操作指南与关键注意事项

1. 升级前，你必须知道的那些“坑”与“宝”

嘿，朋友们，今天咱们来聊聊一个让不少运维和开发同学又爱又恨的话题：MongoDB 大版本升级。特别是从经典的 3.6 版本，一路升级到功能更强大的 4.2 版本。我猜你可能正盯着生产环境里那套运行了好几年的 3.6 集群，心里盘算着：“新版本的聚合管道更香了，事务支持也更完善，好想升级啊！但万一升级过程中服务挂了，数据丢了，这锅我可背不起。”

别慌，这种心情我太懂了。我经历过好几次从深夜到天明的升级拉锯战，也踩过不少坑。今天，我就把自己实战中总结的、确保业务连续性的 MongoDB 3.6 到 4.2 分阶段升级指南 分享给你。这不是一份冷冰冰的官方文档翻译，而是一个老司机带你避坑、保平安的实战手册。我们会把升级拆解成两个清晰的阶段：3.6 -> 4.0，然后 4.0 -> 4.2。每个阶段，我们都会先处理从节点（Secondary），最后再动主节点（Primary），确保服务高可用。

为什么不能直接从 3.6 跳到 4.2？这是 MongoDB 的硬性规定：必须按主要版本顺序升级。官方明确要求，想升级到 4.2，你的集群必须先运行在 4.0 系列版本上。这就像爬楼梯，你得一级一级来，不能直接从三楼跳到五楼。这么做主要是为了确保内部存储格式和功能的平滑过渡，避免出现不可预知的兼容性问题。所以，我们的路线图非常明确：3.6 -> 4.0 -> 4.2。

在动手之前，有件事比升级步骤本身更重要：备份和数据兼容性检查。请务必对你的数据库进行完整备份，无论是用 mongodump 做逻辑备份，还是对数据目录做文件系统快照。这是你的“后悔药”。其次，一定要花时间阅读 MongoDB 4.0 和 4.2 的官方 兼容性变更说明。比如，4.0 版本彻底移除了已弃用的 MMAPv1 存储引擎，如果你的 3.6 还在用这个引擎（虽然可能性很小），升级前必须先转换到 WiredTiger。4.2 版本在索引构建、查询计划等方面也有行为调整。提前用测试环境模拟升级流程，验证你的应用在新版本下是否运行正常，这是避免生产事故最有效的一招。

2. 第一阶段：从 MongoDB 3.6 平稳升级到 4.0

好了，假设你已经做好了万全的备份和测试，咱们正式开始第一阶段的升级。这个阶段的目标是：在保证集群持续提供服务的前提下，将所有节点从 3.6 版本替换为 4.0 版本。核心原则是“先易后难，先次后主”，确保任何时候集群都有可用的主节点。

2.1 升级前的最后确认与准备

在开始替换二进制文件之前，我们还需要做最后几项检查，确保升级路径是通畅的。首先，登录到你的 MongoDB 集群，确认当前的 Primary 节点是哪一个。这很重要，因为我们将最后升级它。你可以通过 mongo shell 连接后执行 rs.status() 命令，查看 members 数组中 stateStr 为 PRIMARY 的节点。或者，用一行命令快速获取：

mongo your_host:27017/admin?replicaSet=your_replset -uyour_user -pyour_pass --authenticationDatabase admin --eval 'printjson(db.isMaster())'

输出中的 primary 字段会告诉你当前主节点的地址。

接下来，检查并设置功能兼容性版本（Feature Compatibility Version, FCV）。这是 MongoDB 版本升级中一个至关重要的概念。FCV 决定了 MongoDB 实例可以使用哪些功能。在升级到 4.0 之前，必须确保 FCV 已经设置为 3.6。运行以下命令检查：

db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })

如果返回的结果中 version 是 3.6，那就没问题。如果不是，你需要先在主节点上执行设置命令（注意，这个命令必须在主节点上运行）：

db.adminCommand({ setFeatureCompatibilityVersion: "3.6" })

这个操作是幂等的，可以安全执行。它确保集群在升级过程中，不会启用 3.6 版本之后的不兼容新特性，为平滑升级铺平道路。

最后，准备好 4.0 版本的安装包。你可以从 MongoDB 官方仓库下载对应你操作系统版本的 RPM 或 DE