首页 > 数据库 >MongoDB 5.0副本集滚动升级到6.0指南

MongoDB 5.0副本集滚动升级到6.0指南

来源：互联网 2026-07-01 08:59:02

MongoDB从5.0升级到6.0，最核心的一条原则——必须逐节点滚动升级，绝不能图省事全量停机或者跳过FCV（Feature Compatibility Version）提升。否则，副本集会卡在STARTUP2状态，或者干脆拒绝选举，新主节点根本没法写入。这不是危言耸听，而是很多运维同行用生产事故

MongoDB从5.0升级到6.0，最核心的一条原则——必须逐节点滚动升级，绝不能图省事全量停机或者跳过FCV（Feature Compatibility Version）提升。否则，副本集会卡在STARTUP2状态，或者干脆拒绝选举，新主节点根本没法写入。这不是危言耸听，而是很多运维同行用生产事故换来的经验。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

为什么不建议直接全量停机？

这里面有几个深层原因。副本集正常运行依赖心跳机制和oplog的同步状态。一旦全量停机，所有节点同时重启，会触发“多数节点失联”的判定。在rs.status()输出中，你会发现多数成员显示为UNKNOWN或DOWN。更麻烦的是，即便所有节点都重新上线，也可能因为FCV不一致、oplog截断，或者electionId冲突，导致长时间选不出主节点。

具体来说，5.0版本默认使用w:majority的writeConcern，而6.0进一步强化了复制一致性校验。节点间FCV不对齐时，SECONDARY节点会拒绝同步新的oplog。从5.0到6.0，必须先把所有节点的二进制文件都升级完，最后再统一提升FCV。如果提前执行setFeatureCompatibilityVersion: "6.0"，那些还没升级的节点会直接崩溃退出。另外，升级过程中任何节点意外终止（比如OOM或磁盘满），如果没有清理mongod.lock文件，下次启动就会报DBPathInUse错误——这都是实际踩过的坑。

滚动升级：每台节点的操作节奏

假设你有一个三节点副本集（1个PRIMARY + 2个SECONDARY），标准流程是这样的，关键在于保证始终有一个可写的主节点：

先连上当前的PRIMARY，执行rs.stepDown(60)主动降级，等新主节点选出来（通常10到30秒左右）。
挑一台SECONDARY节点，执行sudo systemctl stop mongod。
替换二进制文件：Ubuntu上用sudo apt-get install -y mongodb-org=6.0.15 mongodb-org-server=6.0.15，CentOS上则用sudo rpm -U mongodb-org-server-6.0.15-1.el7.x86_64.rpm。
启动服务：sudo systemctl start mongod，然后等待节点状态恢复到SECONDARY。通过rs.status().members[n].stateStr确认，这个过程通常需要1到2分钟，具体取决于oplog的大小。
重复上面的步骤，升级第二台SECONDARY。等它也同步完成后，再对原来那个降级为SECONDARY的原主节点执行相同的升级流程。

FCV提升时机与幂等性验证

这一步很关键，但容易忽略。只有当所有节点都运行6.0的二进制文件，并且rs.status()显示全部是PRIMARY或SECONDARY（没有STARTUP或RECOVERING状态），才能在当前主节点上执行FCV提升：

用mongo或mongosh连接，切换到admin库：use admin。
执行命令：db.adminCommand({ setFeatureCompatibilityVersion: "6.0" })。
验证生效：db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })，如果返回结果中的version字段是"6.0"，那就对了。
这个命令是幂等的，就算失败重试也没问题。但注意，如果返回"node not master"，说明你连到了从节点——必须在主节点上操作。

升级后必查的三个信号

别光看db.version()和rs.status()表面正常就以为万事大吉。很多时候，隐藏的问题要过几个小时才会浮出来：

getLastError报"NotMasterNoSla veOk"：这通常意味着应用的连接池还是旧的，没有触发自动重连。检查驱动是否启用了retryWrites=true，同时确认连接字符串里包含replicaSet=xxx。
慢查询日志里出现大量"waiting for replication"：5.0到6.0后，默认的writeConcern变成了{w: "majority", wtimeout: 60000}。如果某个SECONDARY节点延迟超过60秒，写操作就会超时。可以临时用w=1测试一下，然后排查网络或磁盘I/O的问题。
mongostat显示netIn/netOut突降80%以上：很可能是mongos或客户端缓存了旧的种子节点列表。需要刷新DNS或者重建连接池。