必须先将 featureCompatibilityVersion 设为 "7.0",再按 secondary→primary 顺序滚动升级二进制;驱动需兼容 8.0,升级后须手动执行 setFeatureCompatibilityVersion: "8.0"。

必须先确认 featureCompatibilityVersion 是 "7.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 会导致写入中断、选举震荡,甚至数据回滚。必须按严格顺序滚动替换二进制文件。
- 先关闭一个
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+) - 特别注意:8.0 默认禁用
allowDiskUse在非管理员角色下的使用;若应用依赖此参数,需在对应角色中显式授予enableSharding权限 - 在测试环境跑全量业务流量,重点观察日志中是否出现
"Unsupported wire version"或"Invalid BSON type"类错误
升级后立即检查 storageEngine 和 journal 行为变化
8.0 对 WiredTiger 引擎做了底层优化,但会改变 journal 文件刷盘策略和 checkpoint 间隔——这在高写入负载下可能暴露磁盘 I/O 瓶颈。
- 升级后首次启动时,
mongod会自动重建 journal 文件;如果磁盘空间不足或 inode 耗尽,进程会卡在"Waiting for journal to be initialized" - 检查
storage.journal.enabled是否仍为true(8.0 默认开启),并确认storage.wiredTiger.engineConfig.journalCompressor未被意外设为"none"(压缩关闭会显著增大 journal 占用) - 用
db.serverStatus().wiredTiger.transaction观察update conflicts和checkpoint duration,若后者持续 >30s,说明磁盘吞吐跟不上新 checkpoint 频率
db.adminCommand({ setFeatureCompatibilityVersion: "8.0" })。这个命令不是自动触发的,必须人工执行,否则无法启用 8.0 特有功能(比如新的索引统计精度、$merge 增强语法),而且后续降级也会受阻。


















