MongoDB分片集群不支持在线版本回滚，本质是架构硬限制；必须停机，用旧版本二进制启动config server，手动修复元数据（如删除topologyVersion、补primary字段等），再逐个启动v5.0 shard节点。
为什么 sharded cluster 不能做在线版本回滚
MongoDB 分片集群的元数据（config 数据库）由 config servers 维护，其格式、索引结构、字段语义在大版本升级中常被重构（例如 v5.0 → v6.0 中 shards 集合新增 topologyVersion 字段，databases 集合移除了 primary 字段）。v6.0 的 mongos 会拒绝连接 v5.0 的 config server，反之亦然；降级启动时，mongod 进程直接报错 Invalid config server version: expected 6.x, got 5.x。
真正可行的降级流程：停机 + config server 元数据人工修复
如果你已升级到 v6.0 并发现严重兼容问题（如特定聚合管道崩溃、分片键变更失败），唯一可落地的降级方式是：
- 立即停止所有
mongos和shard节点，只保留config server在线（或从备份恢复） - 用 v5.0 的
mongod启动config server（必须用 v5.0 二进制，v6.0 二进制无法加载旧格式） - 手动清理 v6.0 写入的元数据脏字段：
– 删除config.shards中每个文档的topologyVersion字段
– 将config.databases中缺失primary字段的文档补上（值为原_id对应的 shard 名）
– 检查config.chunks是否含 v6.0 新增的history数组，如有则截断或清空 - 用 v5.0 的
mongos连接该 config server，验证sh.status()能正常输出，且无ERROR: config version mismatch - 逐个启动 v5.0 的
shard节点（注意：v6.0 的数据文件可被 v5.0 读取，但不可写；若 shard 已被 v6.0 写入新 oplog 格式，则需先用mongodump导出再mongorestore回 v5.0 实例）
如何记录元数据变更以便事后修复
升级前不记录 config 库快照，降级时就只能靠猜。必须在升级命令执行前完成：
- 运行
mongodump --host <config-host> --port <port> --db config --out /backup/config-pre-v6 - 额外导出人类可读的元数据摘要：
mongo --host <config-host> --eval "printjson(db.shards.find().toArray())" > shards-pre.jsonmongo --host <config-host> --eval "printjson(db.databases.find().toArray())" > dbs-pre.json - 检查
config.version文档中的lastMod和currentVersion，确认是否为预期值（v5.0 是 5，v6.0 是 6）
注意：mongodump 备份的 config 库不能直接 mongorestore 回集群——它含内部 ObjectId 和时间戳，强行恢复会导致 mongos 拒绝同步。只能用于比对和手工 patch。
容易被忽略的致命细节
很多人以为只要 shard 数据目录没动就能“安全降级”，但以下三点几乎必然导致失败：
- v6.0 的
mongos在升级过程中可能已向config.changelog写入了 v6.0 格式的条目（如moveChunk.start带newTopologyVersion字段），v5.0 的mongos读到就 panic 退出 - 如果启用了
featureCompatibilityVersion: "6.0"（FCV），降级前必须先运行db.adminCommand({setFeatureCompatibilityVersion: "5.0"})—— 但这个命令本身在 v6.0 中已废弃，且仅当所有节点都还在线时才可用；一旦升级完成并重启，FCV 锁死不可逆 - 分片集群的
balancer状态不会自动回滚；即使元数据恢复，sh.getBalancerState()可能返回true，但实际 balancer 进程因版本不匹配已静默失效，导致 chunk 不再迁移，数据倾斜加剧
真正的“平滑”，只存在于升级前的灰度验证和回滚预案里。上线后发现要降级，本质上已是故障响应，不是运维操作。
