Config Server必须是三节点副本集，升级需严格按SECONDARY→PRIMARY顺序滚动进行，mongos须先升至目标版本并保持稳定，升级后须验证configsvr配置、存储引擎及元数据可读性。
Config Server必须是三节点副本集，少一个都不行
从 MongoDB 4.2 开始，config server 强制要求以三成员副本集（CSRS）形式运行。如果你的 config server 是单节点或两节点，升级过程中会直接报 ConfigServerNotFound，整个分片集群立即不可用。这不是警告，是硬性失败。
升级前务必确认：rs.status() 在每个 config server 节点上都返回三个成员，且状态为 PRIMARY、SECONDARY、SECONDARY（不能有 STARTUP 或 RECOVERING）。
- 用
mongosh --host cfg1:27019连任意一个 config server，执行rs.status()查看完整拓扑 - 检查
members[n].stateStr字段，确保没有异常状态 - 确认所有节点配置中仍含
configsvr: true，升级后二进制可能重置该字段（尤其从旧版升级时）
升级顺序只能是 SECONDARY → PRIMARY，不能并行
config server 升级不是“换完就起”，它承载着整个集群的元数据一致性。跳过顺序或同时停多个节点，会导致 sh.status() 输出混乱、chunk 元数据丢失、甚至 mongos 无法加载路由表。
标准滚动步骤：
- 先关一个
SECONDARY节点，替换mongod二进制，启动；等它完成同步、状态回到SECONDARY再继续 - 重复上一步，升级第二个
SECONDARY - 对
PRIMARY执行rs.stepDown()，等新主选举完成、原主变为SECONDARY后，再停机升级 - 切勿在
PRIMARY还没降级前就动其他节点——这会触发不必要的选举风暴
升级后必须立刻验证 configsvr 配置和存储引擎
新版本 mongod 启动时，若配置文件缺失或字段被覆盖（比如 storage.engine 被意外改成 mmapv1），节点可能静默启动但拒绝服务。你不会看到明显错误，但 mongos 会连不上 config server，日志里只有模糊的 Failed to load config。
验证动作要手动做，不能依赖自动检测：
- 登录刚升级的 config server，运行
db.adminCommand({getCmdLineOpts: 1})，确认输出里parsed.configsvr为true - 检查
db.serverStatus().storageEngine.name是否仍为wiredTiger（除非你明确要换引擎） - 执行
db.runCommand({listDatabases: 1})，确认能列出config数据库且其中shards、chunks集合可读
mongos 必须先升，但 config server 升级时 mongos 不能动
很多人误以为“config server 升完就能接着升 shard”，其实中间有个关键空档：mongos 必须比 config server 版本高或至少兼容，但一旦 config server 开始滚动升级，mongos 就不能再重启或切换——否则可能因协议不一致导致路由缓存错乱，出现 OperationNotSupportedInTransaction 或查询返回空结果。
所以真实节奏是：
- 先全部升级 mongos 到目标版本（如 7.0），确认
sh.status()正常、无 WARNING - 再开始 config server 滚动升级，在此期间保持 mongos 进程稳定运行
- config server 全部升完后，再验证
sh.status()和sh.isBalancerRunning()，确认 balancer 可控
最容易被忽略的是：config server 升级过程中，mongos 日志里出现 refreshing config from config server 是正常行为，但若伴随 Failed to refresh config 或长时间无响应，说明某个 config server 节点实际未正确加入副本集——这时候别急着升 shard，得先回退查那个节点的 rs.status() 输出。
