必须确认所有节点fcv为"6.0"，否则升级失败；需用clusteradmin权限执行setfeaturecompatibilityversion；驱动须匹配（如node.js≥5.12.0）；滚动升级顺序为从节点→仲裁节点→主节点；升级后须禁用freemonitoring并启用存储自动伸缩。
升级前必须确认 featureCompatibilityVersion 是 "6.0"
如果 featureCompatibilityVersion 不是 "6.0"，升级会失败或进入不可预期状态。MongoDB 7.0 要求整个副本集所有节点（包括主节点和从节点）的 featureCompatibilityVersion 已设为 "6.0"，否则升级过程会拒绝执行。
连接任意一个副本集成员，运行：
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })
返回结果中 featureCompatibilityVersion 字段值必须为 "6.0"。如果不是，需先在所有节点上统一执行：
db.adminCommand({ setFeatureCompatibilityVersion: "6.0" })
注意：setFeatureCompatibilityVersion 命令需要 clusterAdmin 权限；若启用了访问控制，必须用分片本地用户或具有该权限的管理员账户执行。
驱动版本不匹配会导致连接中断或写入失败
MongoDB 7.0 移除了对旧版驱动的部分兼容逻辑，尤其影响带 Queryable Encryption 的场景。使用 mongodb-driver 4.x 或更早版本的应用，在升级后可能出现 UnsupportedOpCode、InvalidBSON 或静默丢包。
- Node.js 驱动：必须 ≥
5.12.0（支持 7.0 的首个稳定版） - Python PyMongo：必须 ≥
4.7.0 - Java Driver：必须 ≥
4.13.0
检查方式（以 Node.js 为例）：
npm list mongodb
升级命令示例：
npm install mongodb@5.12.0
不要只更新主应用依赖——也要检查所有间接依赖（如 ORM、监控插件、日志中间件），它们可能自带旧版 driver。
升级过程不是“一键完成”，而是逐节点滚动重启
云厂商控制台点“升级7.0”只是触发流程，真正执行时仍需人工干预节点顺序。MongoDB 官方推荐顺序是：先从节点 → 再仲裁节点（如有）→ 最后主节点。跳过这步可能导致选举异常或数据不一致。
实操要点：
- 确保每个节点升级前都处于
SECONDARY状态（主节点需先rs.stepDown()） - 替换二进制文件后，必须用新版本
mongod启动，并验证db.version()返回"7.0.x" - 每次重启后等待
rs.status()显示该节点状态为PRIMARY或SECONDARY且optimeDate追平，再操作下一个 - 禁止同时停多个节点；副本集至少保持
N/2 + 1个节点在线（例如 3 节点集群最多只能 1 个离线）
升级后立即禁用 freeMonitoring 并检查存储自动伸缩
MongoDB 7.0 彻底移除了 freeMonitoring 功能，相关配置项（如 --enableFreeMonitoring、cloud.monitoring.free）将导致启动失败。此外，Atlas 用户若升级到 7.0 后未启用存储自动伸缩，当磁盘利用率超过 90% 时，主节点写入会被阻塞。
检查并清理配置：
- 从
mongod.conf中删除所有含cloud:或enableFreeMonitoring:的行 - 运行
db.disableFreeMonitoring()（即使已废弃，该命令仍可安全执行） - Atlas 用户：进入集群设置 → Storage → 开启
Enable auto-scaling - 自托管用户：监控
db.serverStatus().metrics.repl.apply.ops和磁盘使用率，确认无持续 lag 或 IO stall
最易被忽略的是：升级后首次执行 rs.reconfig() 或添加新节点时，若配置里还残留 freeMonitoring 字段，整个操作会直接报错退出，且错误信息不明确——只会提示 invalid field，需手动排查配置文件。
