MongoDB rolling upgrade (7.0 → 8.0)：replica set 与 sharded cluster

将运行中的 MongoDB 7.0 replica set 或 sharded cluster 不停机（rolling）升级到 8.0：预检查（版本、FCV、成员状态、驱动兼容性）、备份、先升级 secondary，再 stepDown 并升级原 primary；sharded cluster 的顺序为停止 balancer、config server、各 shard、mongos。FCV 8.0 可选择推迟到 burn-in 之后；包含回退选项及其限制。同一主版本内的 patch 更新（8.0.x → 8.0.y）无需更换 repo，按相同的成员顺序进行；从 6.0 升级时须先升级到 7.0。

架构: Replica set（3 个以上成员）或 sharded cluster（config server + 各 shard + mongos）

开始之前

• 所有… mongod（config server 和 shard 成员）及 mongos…成员…均运行 7.0.x，FCV 为 7.0。如果从 6.0 升级，请先升级到 7.0（不能跳过主版本）。
• 没有成员处于 ROLLBACK/RECOVERING/STARTUP2 状态；secondary 落后 primary 仅几秒。
• Oplog 窗口远长于维护时长（每个成员的停机时间），至少数小时。如果过短，停机成员恢复后需要 initial sync。
• 所有应用驱动均为与 MongoDB 8.0 兼容的版本（驱动兼容性表）。旧驱动可能无法连接 8.0，或不支持新行为。
• 已阅读 8.0 兼容性变更页面；未使用任何已移除或已变更的功能（参数、命令、查询行为）。如有条件，已先在测试环境中演练升级。
• 有一份最新且已验证可恢复的备份（snapshot 或 mongodump）。维护窗口已批准。
• 每个成员的数据盘和 /var/log 有足够的可用空间；可以访问 8.0 repo (repo.mongodb.org)。
• Config server 和 shard 成员上的 mongod 以 mongod systemd 服务和 /etc/mongod.conf 运行；mongos 服务器上的服务名为 …。每台服务器只运行一个 mongod/mongos 进程。
• 升级窗口内可以停止 balancer；没有正在进行的 chunk 迁移、resharding 或索引构建。维护期间未计划修改 shard key 或集合元数据。

指南阶段

• 预检查 — 版本、FCV 和角色（所有… mongod…成员…） · 成员状态与复制延迟 · 集群状态、shard 和 balancer · 无效的 system.buckets 集合 · 驱动与兼容性检查 · 备份与回退点 …
• 更换 repo（所有成员） — 添加 8.0 repo，禁用 7.0 repo · 添加 8.0 repo，禁用 7.0 repo
• 逐个升级 secondary — Secondary：确认 … 不是 primary 并停止 · Secondary：在 … 上安装 8.0 binary · Secondary：在 … 上按 8.0 要求配置 THP · Secondary：启动 … 并等待其成为 SECONDARY · Secondary：确认 … 不是 primary 并停止 · Secondary：在 … 上安装 8.0 binary …
• 撤下并升级 primary — 确认 secondary 已运行 8.0 且状态健康 · 撤下 primary (stepDown) · 原 primary：确认 … 不是 primary 并停止 · 原 primary：在 … 上安装 8.0 binary · 原 primary：在 … 上按 8.0 要求配置 THP · 原 primary：启动 … 并等待其成为 SECONDARY
• 停止 balancer — 停止 balancer 并确认迁移已完成
• 启用 balancer 并验证版本 — 确认所有组件已运行 8.0 · 重新启用 balancer
• 验证 — 所有成员已运行 8.0 · 应用与日志检查
• featureCompatibilityVersion 8.0 — 将 FCV 升级到 8.0 · 验证 FCV
• 回退（仅在出现问题时） — 选择回退途径 · 将 binary 回退到 7.0：… · 从备份恢复 · Sharded cluster 的回退顺序