升级前必须统一所有节点的featureCompatibilityVersion为字符串格式的目标版本，逐个验证mongos、配置服务器和分片；mongos版本须≥后端组件；升级后5分钟执行db.checkMetadataConsistency()确认元数据一致。
检查分片集群各组件的 featureCompatibilityVersion
升级前必须确认所有节点的 featureCompatibilityVersion 已统一到目标版本要求的值，否则二进制升级会触发节点崩溃。这个值不是“当前运行版本”，而是 MongoDB 内部用于控制新特性和兼容行为的开关。
- 对每个
mongos、每个配置服务器（config server）副本集的所有成员、每个分片（无论是否为副本集）都需单独连接并执行：db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 }) - 结果中必须全部返回类似
"version": "8.0"—— 注意是字符串，不是数字；且不能存在"version": "7.0"或空字段 - 如果某个分片是独立
mongod实例（非副本集），直接连上去查；如果是副本集，则需逐个连接主从节点，不能只查 primary
验证 mongos 与分片、配置服务器之间的协议兼容性
mongos 是分片路由中枢，它和后端组件之间存在隐式协议协商。版本错配时不会报错，但会出现路由异常、元数据缓存失效、moveChunk 卡住等静默故障。
-
mongos的版本必须 ≥ 所有分片和配置服务器的版本。例如：不能用 7.0 的mongos管理 8.0 分片 - 检查方式：分别在
mongos和各分片/配置服务器上运行mongod --version或mongos --version，比对主版本号 - 特别注意：从 5.0 升级到 6.0 后，
mongos必须手动刷新路由表（sh.refreshRouterConfig()），否则旧缓存可能持续数小时
运行 db.checkMetadataConsistency() 验证升级后元数据一致性
该命令不检查数据内容，只校验分片元数据（如 chunk 分布、tags、shard key 范围）是否在各配置服务器和分片间达成一致。它应在二进制升级完成、集群稳定运行至少 5 分钟后执行。
- 在
admin数据库下运行：db.checkMetadataConsistency() - 默认不检查索引一致性，如需包含索引（例如刚重建过索引），加参数：
db.checkMetadataConsistency({ checkIndexes: true }) - 结果为游标，需遍历查看：
db.checkMetadataConsistency().toArray()—— 若返回空数组，说明元数据一致；否则需根据错误类型（如"ChunkTooBig"、"OrphanedChunk"）进一步处理 - 注意：该方法仅在
mongosh中可用，不是 shell 命令，也不是驱动 API
驱动程序与客户端兼容性常被忽略
分片集群本身能跑，不代表应用能正常读写。尤其当使用较老驱动（如 Node.js 4.x 驱动）连接 8.0 集群时，$lookup、$merge 等聚合阶段可能被静默降级或失败。
- 检查驱动文档中明确标注支持的 MongoDB 最高版本，例如：
Java Driver 4.12 支持 MongoDB 8.0，但 4.11 最高只到 7.0 - 重点验证分片相关行为：带
shardKey的写入是否被正确路由、explain("executionStats")是否显示"executionStages.shards"字段 - 不要依赖
db.version()判断兼容性——它只返回服务端版本，不反映驱动与服务端实际协商的能力
真正容易出问题的地方不在升级那一刻，而在升级后几小时内：元数据不一致可能延迟暴露，驱动降级行为往往只在特定查询路径触发。建议把 db.checkMetadataConsistency() 加入 post-upgrade 自动化巡检脚本，并保留至少一次完整分片均衡日志供回溯。
