必须分组件滚动升级，严格按primary→secondary顺序逐节点操作，先降级fcv再升级二进制，配置服务器和mongos需单独处理，驱动须兼容6.0，写关注需设为majority并验证落盘。
不能靠“全量停机再启动”，必须分组件滚动升级，且每个环节都有状态卡点。否则集群会陷入选举失败、oplog 同步中断、balancer 拒绝恢复等不可写状态。
分片副本集必须逐节点滚动升级，且不能跳过 FCV 提升顺序
每个分片都是一个独立副本集，升级时必须按 PRIMARY → SECONDARY → SECONDARY 顺序逐台操作：
- 先对当前 PRIMARY 执行
rs.stepDown(60)，等待新主选出并稳定至少 30 秒（避免客户端重试窗口内写入失败） - 选中一台 SECONDARY，
sudo systemctl stop mongod→ 替换二进制（如 Ubuntu 上用apt-get install -y mongodb-org=6.0.15）→systemctl start mongod - 等它在
rs.status()中显示stateStr === "SECONDARY"且optimeDate追平主节点（用rs.printSecondaryReplicationInfo()快速验证） - 重复上一步，升级其余 SECONDARY；最后再对原 PRIMARY（现为 SECONDARY）执行同样流程
- 所有节点二进制升级完成后，才可在当前 PRIMARY 上执行：
db.adminCommand({ setFeatureCompatibilityVersion: "6.0" })
提前设 FCV 会导致未升级节点启动失败，报错 Invalid feature compatibility version；FCV 命令必须在主节点执行，否则返回 node not master。
配置服务器和 mongos 必须单独处理，且顺序不可颠倒
配置服务器（config server）是元数据中枢，mongos 是路由入口，二者不参与数据复制，但状态错误会导致整个分片集群不可读写：
- 升级前必须先运行
sh.stopBalancer()，确认sh.getBalancerState()返回false；6.0.3+ 版本虽不再自动 split，但 balancer 仍在管理 chunk 迁移 - 配置服务器要像分片一样滚动升级：先升级所有 SECONDARY，再 stepDown 当前 PRIMARY，最后升级它；不能所有节点同时停机
- mongos 是无状态进程，可直接替换二进制并重启，但必须等所有配置服务器和分片都就绪后再启动，否则会因路由表缺失返回
ShardNotFound或NotMasterNoSlaveOk - mongos 启动后需手动刷新缓存路由表：连接任意 mongos，执行
sh.refreshRouterConfig()
驱动和客户端兼容性是隐形断点，容易被忽略
即使服务端全部跑通，旧驱动也可能让应用静默失败：
- 检查驱动是否支持 MongoDB 6.0 —— Node.js 的
mongodb包需 ≥ 6.0.0，Python 的pymongo需 ≥ 4.7.0；低于版本可能无法解析新 wire protocol 字段 - 禁用所有使用已弃用操作码的驱动（如 v3.6 就标记为 deprecated 的
OP_QUERY），否则升级后出现Unsupported opcode错误 - 应用层必须启用
w: "majority"写关注，并在升级期间加一条带该选项的测试写入，仅看mongosh是否返回成功不够，要验证是否真正落盘 - 如果用了 Stable API，确认你的
apiVersion（如"1"）在 6.0 中仍受支持，否则某些聚合阶段（如$search）会直接报错
最常被跳过的动作是：没等所有分片 SECONDARY 的 optimeDate 追平就升级 PRIMARY，或在配置服务器还没完成 FCV 提升时就重启 mongos。这两个点一旦出错，路由失效和 chunk 元数据不一致会持续数小时，且错误日志里往往只显示模糊的 NotPrimaryNoSecondaryOk 或 StaleConfig。
