必须逐级升级，4.4→5.0是唯一允许的直接路径；FCV须先升至"5.0"且不可逆；二进制需滚动替换，从secondary开始，最后处理primary；升级后须验证索引、TTL行为及驱动兼容性。
必须逐级升级，4.4 → 5.0 是官方唯一允许的直接路径；跳过 4.4（比如从 4.2 直升 5.0）或跨大版本（如 4.4 → 6.0）都会导致 mongod 启动失败、复制中断或数据文件损坏。
确认 FCV 已就绪：别在二进制升级前漏掉这步
Feature Compatibility Version（FCV）不是可选开关，而是 MongoDB 升级的“安全锁”。即使你已把所有节点换成 5.0 的 mongod 二进制，只要 FCV 还是 "4.4"，新版本特性（如默认 readConcern: "local"）就不会启用，且后续降级也受限。
实操要点：
- 先在每个副本集节点上运行：
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })，确认返回值中"version": "4.4" - 升级 FCV 前确保所有节点都已运行 4.4 二进制至少 24 小时，且无
oplog追不上、主从切换异常等隐患 - 执行 FCV 升级命令：
db.adminCommand({ setFeatureCompatibilityVersion: "5.0" })，需在 primary 上执行，且整个副本集必须健康（rs.status()中所有成员状态为PRIMARY或SECONDARY） - FCV 升级不可逆——一旦设为
"5.0"，就不能再降级回 4.4 系列（除非先回退到"4.4"并验证成功）
滚动替换 mongod 二进制：顺序和等待点不能省
滚动升级的本质是“逐个换人，不关店”。但 MongoDB 对顺序敏感：必须从 secondary 开始，最后动 primary，且每次替换后要等新节点完成初始同步（initial sync）或追赶 oplog 到最新位置，否则会触发不必要的全量同步，拖慢进度甚至压垮磁盘 IO。
关键动作：
- 先停一个
SECONDARY节点，用 5.0 的mongod替换旧二进制，启动时确保配置文件中storage.engine和replication.replSetName不变 - 启动后观察日志，直到出现
"transition to PRIMARY" not needed或"replSetSyncFrom"消息稳定，再用rs.status()确认该节点状态回到SECONDARY且optimeDate与 primary 接近（差几秒内） - 重复上述步骤，直到只剩一个
SECONDARY和PRIMARY - 对
PRIMARY执行rs.stepDown()，让它降为SECONDARY；等新选出来的 primary 稳定（约 10–30 秒），再停掉原 primary，替换成 5.0 二进制并重启 - 注意：如果使用 systemd，替换二进制后不要只
systemctl restart mongod，要确认进程 PID 变更、日志里有"MongoDB starting : pid=..."新记录
升级后必验的三件事：别让“看起来正常”骗过你
很多问题在刚启动时不暴露，比如索引重建延迟、TTL 行为变更、驱动协议兼容性。5.0 默认 readConcern: "local" 会让某些带 $lookup 或分片覆盖查询变慢，而 expireAfterSeconds: NaN 会被当成 0 导致 TTL 索引立即删除文档——这些都不会报错，但业务会悄悄出问题。
上线前必须检查：
- 运行
db.runCommand({ listIndexes: "your_collection" })，确认所有索引类型（尤其是text、2dsphere）仍有效，没有变成"state": "unavailable" - 查 TTL 索引：
db.system.indexes.find({ "expireAfterSeconds": { $exists: true } })，若发现NaN值，需重建索引（db.collection.dropIndex(...)+createIndex） - 用生产流量比例 1% 的真实查询压测 10 分钟，重点看
db.currentOp({ secs_running: { $gt: 2 } })是否有异常长事务，以及驱动层是否报"Unsupported OP_MSG"（说明客户端驱动太老）
最易被忽略的是 FCV 与二进制版本的耦合关系：5.0 二进制可以运行在 FCV=4.4 模式下，但反过来，4.4 二进制绝不能加载 FCV=5.0 的数据目录——哪怕只启动一次，也可能永久破坏元数据结构。
