必须将FCV设为"4.4"才能开始从4.4升级到5.0，否则mongod启动失败；升级完成后须手动执行setFeatureCompatibilityVersion:"5.0"以启用新功能，且该操作需在所有节点稳定运行5.0二进制并完成同步后于低峰期执行。
确认 FCV 必须是 "4.4" 才能开始升级
升级前不检查 featureCompatibilityVersion（FCV），mongod 启动时会直接拒绝服务，报错类似：Cannot start server with featureCompatibilityVersion 5.0 when binary version is 4.4。这不是配置错误，而是 MongoDB 强制校验机制——它要求二进制版本和 FCV 必须匹配或“向下兼容”。从 4.4 升级到 5.0，你必须确保所有副本集节点（包括 primary 和 secondaries）的 FCV 都已设为 "4.4"，否则无法推进。
- 连接任一节点执行：
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })，确认返回值中version字段是"4.4" - 如果不是，需在所有节点上统一执行：
db.adminCommand({ setFeatureCompatibilityVersion: "4.4" }) - 该命令仅在主节点运行即可，但必须等所有 secondary 完成同步（
rs.status().members[n].stateStr === "SECONDARY"且optimeDate接近当前时间）后再继续下一步
升级后必须手动提升 FCV 到 "5.0"
安装完 5.0 的 mongod 二进制、重启服务、验证集群状态正常，并不等于升级完成。此时 FCV 仍是 "4.4"，所有 5.0 新功能（如新的聚合阶段 $merge 增强、更严格的 TTL 行为）都处于禁用状态。不提升 FCV，等于白升；提升过早（比如节点还没完全同步完），又可能触发不可逆的数据格式写入，导致降级失败。
- 等所有节点稳定运行在 5.0 二进制上，且
rs.status()显示全部成员状态正常、无延迟后，再连 primary 执行：db.adminCommand({ setFeatureCompatibilityVersion: "5.0" }) - 该操作会触发一次全集群广播，期间不允许写入（短暂阻塞），建议选在低峰期执行
- 执行后立即验证：
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })返回"5.0"，且日志中出现FeatureCompatibilityVersion set to 5.0
FCV 不匹配的典型错误现象
很多升级卡住的问题，其实不是安装失败，而是 FCV 状态混乱导致的行为异常。比如：
- 应用插入文档成功，但用新语法查询（如
$function）报unrecognized pipeline stage name—— 实际是 FCV 还没升，新 stage 被忽略 -
mongorestore恢复失败，提示expireAfterSeconds cannot be NaN—— MongoDB 5.0+ 将NaN视为0，但旧 FCV 下该索引还能建，升级后首次读取就崩 - 副本集选举失败，secondary 日志反复打印
cannot join replica set due to FCV mismatch—— 某个节点 FCV 被漏改，或配置服务器（如果是分片）FCV 没同步
FCV 是单向开关，降级前必须回退
一旦执行了 setFeatureCompatibilityVersion: "5.0"，MongoDB 就可能已写入 5.0 特有的数据格式（例如新的 WiredTiger 元数据结构）。此时若想降级回 4.4，必须先将 FCV 降回 "4.4"，且确保没有 5.0-only 写入发生。官方只保证降级到 4.4 的最新补丁版（如 4.4.27），而不是任意 4.4.x。
- 降级流程必须是：停所有 5.0 节点 → 降级二进制 → 启动 → 立即执行
db.adminCommand({ setFeatureCompatibilityVersion: "4.4" })→ 再验证 - 如果跳过 FCV 回退步骤直接启动 4.4 二进制，服务大概率无法启动，日志报
WiredTiger error: incompatible version - 生产环境强烈建议：FCV 提升后，立刻用
mongodump --forceTableScan做一次全量逻辑备份，这是唯一能跨大版本恢复的兜底方式
