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或者重建连接池。
最后，必须再次强调：FCV提升不可逆。一旦设为"6.0"，5.0的二进制节点就再也无法加入这个副本集。因此，升级前执行mongodump --archive不是走形式，而是底线保障。
