必须停 balancer、逐个升级 config server 和 shard 副本集，并设 fcv 为 "4.0"，因 4.2 强制要求 config server 为副本集且依赖 fcv=4.0 启动，否则报错 configsvr must be run as a replica set 或拒绝加载元数据。
可以平滑滚动升级，但必须停 balancer、逐个升级 config server 和 shard 副本集，并确认 FCV 已设为 "4.0" —— 否则 mongod 启动会拒绝加载旧格式元数据。
为什么不能直接启动 4.2 mongod 替换 4.0 进程
4.2 版本强制要求配置服务器（config server）必须是副本集（CSRS），而 4.0 分片集群可能仍使用旧式三节点独立 config server（即非副本集）。若未提前转换 config server 架构，直接替换二进制会导致 mongod 启动失败并报错：configsvr must be run as a replica set。此外，4.2 默认启用新的 WiredTiger 元数据校验逻辑，若 FCV（Feature Compatibility Version）仍为 "3.6" 或未显式设为 "4.0"，mongod 会拒绝启动以防止元数据损坏。
- 检查当前 FCV：
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })，输出中"version"必须是"4.0" - 若不是，先在 4.0 主节点执行：
db.adminCommand({ setFeatureCompatibilityVersion: "4.0" })，再等待所有成员同步完成 - 确认 config server 已是副本集：连接任意 config server，运行
rs.conf()，有_id和members字段才算 CSRS
滚动升级时 mongos 要不要重启
需要重启，但可分批进行，不影响客户端连接。4.2 的 mongos 二进制与 4.0 不完全兼容——尤其涉及 chunk 拆分策略和路由缓存刷新机制的变更。旧版 mongos 连接 4.2 mongod 可能出现 stale config、路由错误或无法识别新返回字段（如 operationTime 扩展），最终表现为查询返回空结果或超时。
- 升级顺序：先升级所有 config server → 再升级所有 shard 副本集 → 最后批量重启
mongos -
mongos无状态，重启不中断连接；但建议控制并发重启数量（例如每次最多 2 个），避免客户端重连风暴 - 验证方式：连接新
mongos，执行sh.status()，确认sharding version显示为4.2且各 shard 状态为ONLINE
升级后必须立刻验证的三项操作
很多团队升级完就认为结束，结果第二天才发现 chunk 迁移卡住、索引失效或聚合管道行为异常。4.2 引入了新的默认排序规则（collation）、更严格的 $lookup 引用检查，以及对 maxTimeMS 在分片场景下的传播修正，这些都需实测确认。
- 触发一次手动 chunk 拆分：
sh.splitAt("db.coll", { _id: ObjectId() })，观察是否成功写入 config.chunks 并被 mongos 正确路由 - 在分片集合上建一个带
collation: { locale: "en" }的索引，再用相同 collation 查询，确认能命中 - 执行跨分片
$lookup，目标集合也需分片，检查是否返回完整结果而非仅本地分片数据（4.0 中此问题常见，4.2 已修复但需验证）
最易被忽略的是 config server 升级后的 oplog 大小。4.2 对 config server 的 oplog 写入更频繁（尤其 balancer 活跃时），若沿用 4.0 默认的 1GB oplog，可能数小时内填满导致复制延迟飙升。升级 config server 后，务必登录其副本集，运行 rs.printReplicationInfo()，确认 oldest 时间点距当前不超过 2 小时；否则用 rs.replSetResizeOplogSize(5120) 扩容到至少 5GB。
