MongoDB 5.0副本集如何平滑升级至6.0版本_按照官方滚动升级指南逐一更替节点

必须逐节点滚动升级，不能全量停机或跳过FCV提升，否则副本集会卡在STARTUP2或拒绝选举，新主无法写入。

必须逐节点滚动升级，不能直接全量停机或跳过 FCV 提升 —— 否则副本集会卡在 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 错误

滚动升级每台节点的具体操作顺序

以三节点副本集（PRIMARY + 2×SECONDARY）为例，按以下顺序逐台操作，确保始终有可写主节点：

• 先连接当前 PRIMARY，执行 rs.stepDown(60) 主动降级，等待新主选出（通常 10–30 秒）
• 选中一台 SECONDARY 节点，执行 sudo systemctl stop mongod
• 用 APT/YUM/RPM 替换二进制：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 → 等待 rs.status().members[n].stateStr === "SECONDARY"（通常需 1–2 分钟，取决于 oplog 大小）
• 重复以上步骤，升级第二台 SECONDARY；最后等它同步完成，再对原 PRIMARY（现为 SECONDARY）执行相同流程

FCV 提升时机与幂等性验证

只有当所有节点都运行 6.0 二进制且 rs.status() 显示全部为 PRIMARY/SECONDARY（无 STARTUP/RECOVERING）后，才能在当前 PRIMARY 上执行 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 报错 "NotMasterNoSlaveOk"：说明应用仍连着旧连接池，没触发自动重连；检查驱动是否启用 retryWrites=true，并确认连接字符串含 replicaSet=xxx
• 慢查询日志里大量 "waiting for replication"：5.0→6.0 默认 writeConcern 变更为 {w: "majority", wtimeout: 60000}，若某 SECONDARY 延迟 >60s，写操作会超时；临时可加 w=1 测试，再排查网络或磁盘 I/O
• mongostat 显示 netIn/netOut 突降 80%+：可能是 mongos 或客户端缓存了旧的种子节点列表，需刷新 DNS 或重建连接池

FCV 提升不可逆，一旦设为 "6.0"，5.0 二进制节点将无法加入该副本集 —— 所以升级前那句 mongodump --archive 不是仪式，是底线。