升级MongoDB 5.0前必须先将所有节点升至4.4最新补丁版并设fcv为"4.4"，清理NaN TTL索引，按配置服务器→分片→mongos顺序滚动升级，并验证驱动兼容性。
必须先将所有分片、配置服务器和 mongos 实例升级到 4.4 的最新补丁版本（如 4.4.27），再统一升到 5.0；跳过 4.4 最新版直接升 5.0，极大概率触发兼容性校验失败或启动异常。
确认所有节点 featureCompatibilityVersion 已设为 "4.4"
5.0 升级前强制要求整个分片集群的 featureCompatibilityVersion 是 "4.4"，不是 "4.2" 或空值。这个值不等于 MongoDB 二进制版本号，而是独立控制新特性开关的参数。
- 逐个连接到每个分片副本集的主节点、每个配置服务器副本集的主节点、以及任意一个
mongos，执行：db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 }) - 只要任一节点返回
"version": "4.2"或报错"no such command"（说明未设置），就必须立刻设为"4.4"：db.adminCommand({ setFeatureCompatibilityVersion: "4.4" }) - 设完后等待几秒，再查一次——部分节点需主从同步后才生效，不能只查一次就认为完成
检查 TTL 索引是否含 expireAfterSeconds: NaN
MongoDB 5.0 将 NaN 视为 0，会导致意外立即删除数据。4.4 允许存但不警告，5.0 启动时会拒绝加载这类索引。
- 在每个分片上运行：
db.runCommand({ listIndexes: "<collection_name>" }).cursor.firstBatch.forEach(i => { if (i.expireAfterSeconds !== undefined && isNaN(i.expireAfterSeconds)) printjson(i) })</collection_name> - 对命中结果，用
db.<collection_name>.dropIndex(...)</collection_name>删除该 TTL 索引，或重建为合法值（如3600） - 注意：配置服务器上也可能存在系统级 TTL 索引，别漏掉
config数据库
滚动升级顺序不能乱：配置服务器 → 分片 → mongos
顺序错会导致元数据不一致或 mongos 启动失败。配置服务器必须最先升，因为分片和 mongos 启动时会向它拉取集群状态。
- 停一个配置服务器节点：
db.shutdownServer()，替换mongod二进制，用--configsvr和原配置重启 - 等该节点
rs.status().members[n].stateStr === "PRIMARY"或 "SECONDARY" 且无"health": 0后，再操作下一个 - 所有配置服务器升完，再按同样方式逐个升级分片副本集成员（先从节点，最后主节点）
- 最后升级所有
mongos进程——它们不存数据，替换二进制后直接启动即可
驱动与客户端必须提前验证兼容性
5.0 移除了对 SCRAM-SHA-1 认证机制的默认支持，且部分聚合管道操作符行为变更。服务端升级完成 ≠ 应用能连上。
- 检查你用的驱动版本是否明确标注支持 MongoDB 5.0（例如 Node.js 驱动 v4.13+，Python PyMongo v4.6+）
- 在测试环境用真实流量压测，重点观察：
— 是否出现AuthenticationFailed错误（可能因服务端禁用了旧认证方式）
— 聚合查询结果是否多/少数据（如$facet在 5.0 对空数组处理更严格） - 若发现不兼容，不要强行上线——要么降级驱动，要么改应用代码，5.0 不提供向前兼容的降级开关
最容易被忽略的是配置服务器副本集的 buildIndexes: false 要求：如果某个配置服务器成员启用了索引构建（比如手动改过配置），5.0 启动时会直接拒绝加入集群，错误信息藏在日志里，不报在 shell 中。
