将 MongoDB 7.0 副本集升级到 MongoDB 8.0 时，步骤顺序必须严格执行：先确认并将 featureCompatibilityVersion 设置为 "7.0"，再按照 secondary→primary 的顺序逐台进行二进制滚动升级；同时，还要提前验证应用驱动是否兼容 8.0。全部升级完成后，最后一步不要遗漏，需要手动执行 setFeatureCompatibilityVersion: "8.0"。

必须先确认 featureCompatibilityVersion 是 "7.0"

在 MongoDB 7.0 升级到 MongoDB 8.0 之前，如果不先检查 featureCompatibilityVersion，这是最常见的升级失败原因之一。MongoDB 8.0 要求所有副本集成员的 FCV 都已经设置为 "7.0"，否则节点在启动时可能直接崩溃，或拒绝加入副本集。

• 依次连接每个节点（包括 primary 和所有 secondary），执行：
  db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })
• 返回结果中必须包含 "featureCompatibilityVersion" : { "version" : "7.0" }；如果返回的是 "6.0"，或出现 "no such command" 报错，说明当前还没有完成 7.0 的 FCV 升级，此时不能继续升级到 8.0
• 如果 FCV 尚未就绪，需要先在所有节点执行 db.adminCommand({ setFeatureCompatibilityVersion: "7.0" })，然后等待数据复制完成并确认集群状态稳定

滚动升级顺序不能乱：secondary → primary

如果直接重启 primary，很容易造成写入中断、频繁选举，甚至引发数据回滚。正确做法是按照 MongoDB 官方推荐方式，严格遵循 secondary 到 primary 的顺序进行滚动升级。

• 先停止一个 secondary 节点，使用 MongoDB 8.0 的 mongod 二进制替换旧版本文件，并同步检查配置项（如 binPath、日志路径等），然后重新启动
• 等待该节点状态恢复为 "SECONDARY"，并且 optimeDate 追平其他成员（可通过 rs.status() 查看）
• 重复以上流程，直到全部 secondary 都升级为 8.0；此时虽然 primary 仍运行 7.0，但整个副本集依然可以正常提供读写服务
• 最后对当前 primary 执行 rs.stepDown()，触发新一轮选举，让一个已升级到 8.0 的 secondary 成为新的 primary，再关闭原来的 primary 并完成升级

驱动和客户端兼容性必须提前验证

MongoDB 8.0 移除了部分旧版协议支持，同时默认启用了更严格的认证机制和类型校验规则。如果仍使用旧驱动连接 8.0，表面上可能能够连接成功，但某些聚合管道、查询或更新操作可能会出现静默失败的问题。

• 确认当前使用的驱动版本已明确声明支持 MongoDB 8.0（例如 Node.js driver v6.7+、Python PyMongo v4.10+）
• 特别注意：MongoDB 8.0 默认禁止非管理员角色使用 allowDiskUse；如果业务依赖这个参数，需要在对应角色中显式授予 enableSharding 权限
• 建议先在测试环境中跑完整业务流程，重点排查日志里是否出现 "Unsupported wire version" 或 "Invalid BSON type" 等兼容性错误

升级后立即检查 storageEngine 和 journal 行为变化

MongoDB 8.0 对 WiredTiger 存储引擎进行了底层优化，但与此同时，也会影响 journal 刷盘策略以及 checkpoint 的执行间隔。这类变化在高并发写入场景下，往往更容易暴露磁盘 I/O 瓶颈。

• 升级后的首次启动过程中，mongod 会自动重建 journal 文件；如果磁盘空间不足，或者 inode 已耗尽，进程可能卡在 "Waiting for journal to be initialized"
• 检查 storage.journal.enabled 是否仍然为 true（MongoDB 8.0 默认开启），并确认 storage.wiredTiger.engineConfig.journalCompressor 没有被误设为 "none"（关闭压缩会明显增加 journal 占用空间）
• 通过 db.serverStatus().wiredTiger.transaction 观察 update conflicts 和 checkpoint duration，如果后者持续大于 30 秒，通常说明磁盘吞吐能力跟不上新的 checkpoint 频率