必须先升级mongos，因其是客户端唯一入口且对后端版本有严格兼容要求；低版本mongos连接高版本config server或shard可能因协议变更（如clustertime格式调整）拒绝连接或静默丢弃请求。
MongoDB 分片集群升级不能跳步，必须按 mongos → config server → shard replica set 顺序滚动升级，否则会触发元数据不一致、路由失效或写入阻塞。
为什么必须先升 mongos？
mongos 是客户端请求的唯一入口，它对后端组件版本有严格兼容要求。低版本 mongos 连接高版本 config server 或 shard 时，可能因协议变更（如 6.0 引入的 clusterTime 格式调整）直接拒绝连接，报错 Unsupported version 或静默丢弃请求。
- 升级前确认所有
mongos实例版本 ≥ 目标config server和shard的最低兼容版本（查官方 Release Notes 中 “Compatibility” 表） - 逐台重启
mongos，不要批量停机；新旧mongos可共存，但混用期间禁止执行sh.addShard()或sh.removeShard() - 验证：连上新
mongos执行sh.status()，确认能正常返回分片拓扑且无WARNING: mongos is older than config servers
config server 升级必须用 replica set 模式且三节点全升
4.2+ 版本强制要求 config server 必须是三成员副本集（csrs），单节点或两节点升级会导致 ConfigServerNotFound 错误，分片集群彻底不可用。
- 确保三个
config server节点在升级前状态均为PRIMARY/SECONDARY，无STARTUP或RECOVERING - 按
SECONDARY→PRIMARY顺序滚动升级：先关一个SECONDARY，替换二进制，启动；等其同步完成、状态变SECONDARY后再操作下一个；最后对PRIMARY执行rs.stepDown()再升级 - 升级后立刻检查
db.adminCommand({getCmdLineOpts: 1})确认configsvr: true仍在配置中，且storage.engine未被意外重置（尤其从 WiredTiger 切到其他引擎会失败）
升级 shard 副本集要避开 chunk 迁移窗口
在 shard 升级过程中，若发生 chunk 迁移，新旧版本 mongod 对迁移协议理解不一致（如 7.0 的 moveChunk 增加了 writeConcern 校验），会导致迁移卡住、sh.status() 显示 chunk(s) under migration，甚至数据不一致。
- 升级前执行
sh.stopBalancer()，并确认sh.getBalancerState()返回false，同时等待sh.isBalancerRunning()返回false（可能需数分钟） - 逐个升级每个
shard的副本集：同样按SECONDARY→PRIMARY顺序；升级PRIMARY前先rs.stepDown()，避免选举干扰 - 每个
shard升级完成后，运行db.runCommand({collStats: "any_collection"})验证能否正常访问数据，再开启下一轮升级；切勿等全部shard升完才验证
最容易被忽略的是 mongos 和 config server 之间的认证机制变化——比如 6.0 默认启用 SCRAM-SHA-256，而老 mongos 只支持 SCRAM-SHA-1，这时即使版本“兼容”，也会在连接 config server 时静默失败。升级前务必核对 security.authenticationMechanisms 配置是否匹配。
