必须按4.4→5.0→6.0分步升级，跳过中间版本会导致服务启动失败、数据损坏或索引异常；需严格同步FCV变更、逐节点升级副本集、适配驱动与配置参数。
不能直接从 4.4 升级到 6.0，必须先升级到 5.0，再升到 6.0。
必须走 4.4 → 5.0 → 6.0 的分步路径
跳过中间主版本（比如直接 mongod 替换二进制）会导致服务启动失败、数据损坏或索引异常。MongoDB 官方明确禁止跨版本升级，因为：
-
featureCompatibilityVersion（FCV）是硬性门槛：4.4 副本集必须先设为"4.4"，升级到 5.0 后再设为"5.0"，最后才能升到 6.0 并设为"6.0" - WiredTiger 存储引擎格式在 5.0 和 6.0 中均有调整，跳过会触发校验失败
- 某些命令（如
collMod参数）、聚合行为（allowDiskUse默认逻辑）在 5.0 已变更，6.0 又进一步收紧
升级前必须检查驱动和应用兼容性
很多问题不是数据库挂了，而是应用连不上或查不出数据——尤其容易被忽略：
- Python 的
pymongo：4.4 用的pymongo==3.12在 6.0 上可能无法解析新格式的$searchMeta或变更流恢复令牌 - Java 驱动：若仍用
mongo-java-driver（已废弃），必须换成mongodb-driver-sync4.11+ 版本 - 应用代码里显式用了已移除功能：如
db.eval()（5.0 起禁用）、geoNear的旧语法、text索引与通配符索引混用 - 监控工具（如 Prometheus exporter）若硬编码了
/adminCommand接口路径，6.0 的权限模型变更可能导致采集失败
副本集节点必须逐个升级，且顺序不能错
Secondary 先升、Primary 最后升，不是可选项，是强制要求：
- 升级 Secondary 时，确保它已完成同步（
rs.status().members[n].stateStr === "SECONDARY"且optimeDate接近 Primary） - Primary 降级前，先运行
rs.stepDown(60)让它主动让位，避免强制切换引发写入丢失 - 每个节点重启后，必须等
rs.status().members[n].health === 1且stateStr恢复为"SECONDARY"或"PRIMARY"才能操作下一个 - 升级完一个节点后，不要立即改 FCV；等所有节点都跑在新二进制上，再统一执行
db.adminCommand({setFeatureCompatibilityVersion: "X.0"})
配置文件和磁盘空间容易踩坑
6.0 对配置项和资源更敏感，几个关键点：
-
storage.wiredTiger.engineConfig.journalCompressor：4.4 默认"snappy"，6.0 强制要求"zstd"，不改会导致mongod启动报错 -
net.ssl.mode：6.0 默认值从"preferSSL"改为"requireSSL"，没配证书的服务会直接拒绝连接 -
allowDiskUseByDefault: true：6.0 开始默认启用磁盘临时文件，如果/var/lib/mongodb所在分区只剩不到 10GB，聚合查询可能因空间不足静默失败 - 日志轮转：6.0 默认启用
systemLog.logRotate: "rename"，但若systemLog.path所在目录 inode 不足，mongod会卡在启动阶段
最麻烦的不是升级动作本身，而是 FCV 切换和驱动适配——这两步出问题，服务看起来正常，但应用侧会出现间歇性超时或空结果，排查成本远高于停机窗口内的操作。
