分片集群各组件版本不一致会导致元数据同步失败，必须严格遵循官方版本兼容矩阵升级顺序：先config server→再shard→最后mongos，且fCV需与最低版本组件一致，升级后须重启mongos并验证配置。
分片集群各组件版本不一致会直接导致元数据同步失败
MongoDB 分片集群里 mongos、shard（即 mongod 实例）、config server 必须满足官方文档定义的「版本兼容窗口」，超出范围就会拒绝连接或静默丢弃请求。比如 mongos 6.0 连接 mongod 5.0 shard，看似能连上，但执行 sh.addShard() 或路由变更时，config server 可能返回 InvalidOptions: incompatible version 而不是明确报错，日志里只有一行 Failed to refresh routing table。
实操建议：
- 升级前查清当前所有组件版本：
db.version()（在每个mongos和mongod上分别执行）；mongos --version；mongod --version - 严格按官方《Version Compatibility Matrix》顺序升级：先 config server → 再所有 shard → 最后 mongos；中间不能跳步
- 禁止跨大版本直接升级（如从 4.4 直升 6.0），必须经 5.0 中转，否则
featureCompatibilityVersion (fCV)无法降级
fCV 不是可选开关，而是强制兼容锁
featureCompatibilityVersion 是 MongoDB 控制新旧行为共存的硬开关，不是“启用某功能”的配置项。它一旦设为 "6.0"，所有节点就默认启用 6.0 的元数据格式和协议，老版本 mongos 或 shard 就读不懂新格式的 chunk 分配信息，导致 balancer 卡死、查询路由错误甚至数据写入丢失。
实操建议：
- 升级完一批节点后，立刻在
admin数据库运行：db.adminCommand({setFeatureCompatibilityVersion: "6.0"})—— 注意：该命令必须在所有目标节点都升级完毕后，由mongos或任意config server发起 - 升级过程中，
fCV必须保持与最低版本组件一致，例如 shard 还有 5.0 实例，则fCV不能设为"6.0"，否则 config server 拒绝写入新 chunk 元数据 - 检查当前
fCV值用：db.adminCommand({getFeatureCompatibilityVersion: 1})，返回字段是version，不是featureCompatibilityVersion
mongos 升级后无法发现新 shard 的典型原因
常见现象是 sh.status() 里看不到刚加的 shard，或者 sh.addShard("rs2/...") 返回成功但后续无响应。根本原因常是 mongos 缓存了旧版 config server 的路由表结构，而新版 config server 已用新协议返回数据，mongos 解析失败后静默 fallback 到空路由表。
实操建议：
- 每次
mongos升级后，必须重启进程，不能靠SIGHUP或热重载 —— 它的路由缓存和连接池是进程级初始化的 - 确认
mongos是否已连接到正确的 config server：用db.runCommand({getCmdLineOpts: 1})查configdb配置值，注意是否还指向旧地址或 DNS 缓存未刷新 - 临时验证可用性：在
mongos上执行db.runCommand({listShards: 1})，如果返回空或报NotMaster，说明它没连上 config server 或 config server 版本太低
滚动升级时最容易被忽略的 config server 配置陷阱
很多人以为 config server 只是“存配置”，升级时随便停一个副本就行。实际上，MongoDB 4.4+ 的 config server 必须是 3 节点副本集（不再支持单节点），且 mongod 启动时若检测到 --configsvr 但 fCV 不匹配，会直接退出并打印 incompatible fCV for config server，而不是等待手动修正。
实操建议：
- config server 升级必须 3 节点逐个滚动，且每台重启前确认其
fCV已提前设为目标版本（通过连接其他存活 config 节点执行setFeatureCompatibilityVersion） - 启动参数中
--configsvr和--replSet必须同时存在，缺一不可；遗漏--replSet会导致实例以单节点模式启动，后续无法加入副本集 - 升级后立即验证 config server 状态：
rs.status()在任意 config 节点上执行，确保stateStr全是PRIMARY或SECONDARY，没有STARTUP或RECOVERING长时间存在
真正麻烦的从来不是命令敲错，而是某个 config server 节点的 fCV 卡在旧值、或者 mongos 进程没重启却以为自己已生效——这些状态不会报错，只会让集群慢慢失联。
