分片集群滚动升级必须严格按顺序停服务、分步操作：先停balancer，再依次升级config server、分片、mongos，最后统一设置fcv；任一环节跳过或验证缺失，均可能导致迁移卡住、路由错误或集群只读。
分片集群滚动升级不是“能不能做”，而是“必须按顺序停哪些服务、先动哪部分、参数怎么配”。跳过任一环节，轻则 balancer 卡住、chunk 迁移中断，重则 config server 不同步、mongos 拒绝路由，整个集群变只读甚至不可用。
为什么要先停 balancer
balancer 是分片集群里最活跃的后台进程，它持续检查 chunk 分布并触发迁移。升级过程中如果让它继续运行，会出现两种典型故障：sh.stopBalancer() 未执行或执行后未确认返回 false，导致新旧版本 mongod 在迁移途中互相不认协议；或者迁移一半时某个分片升级完成，但 config server 还没同步元数据，结果 chunk 被“卡”在中间状态，查 sh.status() 会看到 Chunk(s) pending migration 且长期不消失。
实操建议：
- 连接任意
mongos执行sh.stopBalancer()，再立刻跑sh.getBalancerState()确认返回false，不能只看命令没报错就认为成功 - 升级全程保持 balancer 停止，直到所有分片、config server、mongos 全部升级完毕，且
featureCompatibilityVersion统一后，再用sh.startBalancer() - 如果升级中途意外中断，重启 balancer 前务必先运行
sh.waitForBalancer()等待迁移队列清空，否则可能触发冲突
配置服务器和分片必须分开滚动
config server 和分片虽然都是副本集，但角色不同：config server 存的是全局元数据（如 shard key 映射、chunk 分布表），分片存的是实际数据。它们的升级顺序不能颠倒，也不能混着升——比如先升一个 config 节点、再升一个分片节点，会导致 config 版本高于分片，mongos 读不到最新路由表，查询直接报 ShardNotFound 或路由到错误分片。
实操建议：
- 先对所有 config server 副本集执行完整滚动升级（逐个 secondary 关闭 → 替换二进制 → 启动 → 等
rs.status()显示 PRIMARY 切换完成 → 再动下一个），全部完成后才开始动分片 - 每个分片副本集内部按标准滚动流程：先关 secondary → 升级启动 → 等同步追平 →
rs.stepDown()降级 primary → 让新版本 secondary 成为 new primary - 切记：不要跨分片并行升级多个 secondary，尤其当它们属于不同副本集时——你无法控制哪个分片的 secondary 先完成同步，容易造成 mongos 缓存不一致
mongos 升级最容易被忽略的兼容性陷阱
mongos 是无状态路由层，看起来升级最简单，但它对底层 mongod 的协议版本极其敏感。7.0 的 mongos 如果连着 6.0 的分片，某些聚合管道（比如带 $merge 或 $facet 的复杂查询）会静默失败或返回截断结果；更隐蔽的是，sh.addShard() 或 sh.splitAt() 这类 DDL 操作可能卡在 waiting for config server response 状态，日志里只显示 Failed to refresh metadata，根本不会报具体版本错。
实操建议：
- mongos 必须最后升级，且必须等所有 config server 和分片节点的
db.adminCommand({getParameter:1, featureCompatibilityVersion:1})返回一致版本（例如"version" : "7.0"）后再操作 - 升级 mongos 二进制后，不要直接重启服务，先用
mongos --version确认输出是目标版本，再检查ps aux | grep mongos确保旧进程已彻底退出（常见坑：systemd reload 没杀干净旧进程） - 升级后立刻在 mongos 上跑
sh.status()和db.runCommand({listShards:1})，验证所有分片 status 为OK且 version 字段匹配，否则说明某一分片没真正升级到位
featureCompatibilityVersion 不是可选项
FCV（feature compatibility version）不是升级完自动更新的开关，而是 MongoDB 强制要求的“协议协商锁”。哪怕所有节点二进制都换成 7.0，只要 FCV 还是 "6.0"，你就没法用 7.0 的新特性（比如新的索引类型、更严格的唯一约束校验），而且某些驱动行为会退化——Java 驱动 4.11+ 默认启用 retryWrites=true，但在 FCV=6.0 的 7.0 集群上，这个 retry 实际不生效，写失败后直接抛异常。
实操建议：
- FCV 升级必须在所有节点二进制升级完成后、业务流量切回前执行，命令是
db.adminCommand({setFeatureCompatibilityVersion:"7.0"})，需在每个 config server 和每个分片的 primary 上单独运行 - 执行前务必确认所有节点 FCV 当前值（用
db.adminCommand({getParameter:1, featureCompatibilityVersion:1})），如果有任何一个返回6.0，FCV 设置会失败并报错Cannot set featureCompatibilityVersion when nodes are not at the same version - FCV 提交后，再查一遍所有节点，确保全部返回
"version" : "7.0"；此时才能认为升级真正完成，否则 mongos 可能拒绝执行某些命令，比如sh.enableSharding()
滚动升级真正的难点不在命令本身，而在于“状态确认”——每个环节结束后，你得亲手验证节点角色、同步状态、FCV 值、balancer 开关、mongos 路由表这五样东西是否全部符合预期。少看一眼日志，就可能让集群在后续几天里间歇性丢请求，排查起来比重装还费劲。
