mongodb 6.0分片集群升级至7.0必须严格逐节点滚动升级，不可跳步或全量替换；需先确保所有组件运行6.0.x且fcv设为"6.0"，再按mongos→config server→分片顺序升级，最后统一执行setfeaturecompatibilityversion:"7.0"。
必须逐节点滚动升级，不能跳过中间版本，也不能一次性全量替换二进制文件。MongoDB 6.0 分片集群升级到 7.0 是一个受控、分阶段的过程，任何跳步或忽略 FCV 检查都会导致配置服务器拒绝服务或分片路由失效。
确认所有组件满足 6.0 起始要求
升级前必须确保整个分片集群所有角色都已运行在 MongoDB 6.0 系列（如 6.0.15），且 featureCompatibilityVersion 已显式设为 "6.0"：
- 连接每个分片副本集的 primary，执行
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })，确认返回值为{ "featureCompatibilityVersion" : { "version" : "6.0" } } - 同样检查所有 config server 副本集成员 —— 缺少任一 config server 的 FCV 同步，
mongos将无法加载分片元数据 - 检查
mongos进程版本：它不存储数据，但必须能与 7.0 分片通信；建议先升级mongos到 7.0，再升级分片节点（避免路由表陈旧） - 若发现某分片仍为
5.0.22，必须先升至6.0.x并完成 FCV 设置，否则升级脚本会中止
按角色顺序滚动升级二进制与配置
顺序错误会导致集群短暂不可写或路由错乱。不要并行升级所有分片，也不要先动 config server：
- 第一步：停掉所有
mongos实例，用 MongoDB 7.0 的二进制替换，并更新其配置文件中的configDB地址（如有变更）；重启后验证sh.status()是否可读 - 第二步：逐个升级 config server 副本集 —— 每次只对一个 secondary 执行停机 → 替换二进制 → 启动 → 等待状态变为
SECONDARY→ 再切 primary → 重复。全部完成后，再次确认rs.status()中无STARTUP2或RECOVERING - 第三步：对每个分片副本集，采用相同滚动方式升级（primary 最后升）；升级完一个分片后，立即运行
sh.getShardDistribution()确认 chunk 分布未异常偏移 - 升级后首次连接任意分片，执行
db.runCommand({ setFeatureCompatibilityVersion: "7.0" })—— 此命令必须在所有节点升级完毕且稳定运行至少 5 分钟后执行
驱动与应用层兼容性陷阱
7.0 默认启用更严格的写关注（w: majority）和新的事务语义，老驱动可能静默失败：
- Node.js 驱动需 ≥
6.7.0，Python PyMongo ≥4.7.0；低于版本可能无法解析$searchMeta或新聚合阶段 - 若应用使用
maxTimeMS在聚合中，7.0 对超时判断更严格，部分长查询可能提前中断 —— 建议在 staging 环境用mongostat --host <shard></shard>观察query和getmore延迟突增 - 禁用
Latest Version With Auto Upgrades选项（Atlas 用户）；该开关会绕过人工 FCV 控制，直接拉取8.2，而 8.2 不支持当前mongosync迁移路径 - 升级后首次写入，检查日志是否有
WriteConflict频发 —— 这常因应用仍用 6.0 事务重试逻辑，在 7.0 更激进的锁策略下暴露
最易被忽略的是 config server 的 FCV 同步时机：它不随分片自动升级，必须手动逐个确认并执行 setFeatureCompatibilityVersion。漏掉一个 config server 节点，整个集群的 moveChunk 操作就会卡住，且错误日志里只显示模糊的 “metadata refresh failed”。
