startup2或recovering迟迟不转secondary说明oplog不可追或本地数据冲突；常见原因包括oplog过小、节点宕机太久、磁盘损坏；应清空dbpath后重启触发initial sync。
副本集节点状态显示 STARTUP2 或 RECOVERING 却迟迟不变成 SECONDARY
这通常说明该节点无法追上主节点的 oplog，或本地数据与主节点存在不可自动修复的冲突。常见原因包括：oplog 太小导致历史操作被覆盖、节点宕机太久、磁盘损坏导致 journal 或数据文件异常。
实操建议：
- 先在该节点上执行
rs.status()，确认optimeDate是否远落后于PRIMARY的optimeDate - 检查
db.getSiblingDB("local").oplog.rs.stats()中的size和maxSize，若size接近maxSize且count明显偏少，说明 oplog 被频繁截断——这是典型容量不足信号 - 不要直接重启；先停掉 mongod，清空该节点的
dbpath（保留mongod.lock可删），再以--replSet启动，它会触发完整同步（initial sync） - 注意：初始同步期间会删除本地所有数据，并从 PRIMARY 拉取全量快照 + 回放后续 oplog，耗时取决于数据量和网络带宽
rs.printSlaveReplicationInfo() 显示延迟秒数持续增长
延迟不是“卡住”，而是 SECONDARY 在持续 lag，可能因硬件性能差、查询负载高、或网络抖动导致心跳超时误判。但更危险的是：延迟过大后，PRIMARY 的 oplog 已滚动覆盖旧条目，该节点再也无法追平。
实操建议：
- 用
db.adminCommand({ "replSetGetStatus": 1 })查看每个节点的lastHeartbeatMessage，确认是否有 “could not find member” 或 “not reachable” 类错误 - 检查系统资源：
mongostat观察netIn/netOut是否长期打满；iostat -x 1看%util是否持续 >90% - 临时降低延迟敏感度：在 PRIMARY 上执行
rs.conf()获取配置，修改settings.heartbeatTimeoutSecs从默认 10 改为 30（需rs.reconfig()生效），避免误踢健康节点 - 禁止在 SECONDARY 上运行写操作或重负载聚合查询——它们会争抢 oplog 应用线程的 CPU 和 I/O
执行 rs.syncFrom() 后仍不同步
手动指定同步源本应加快追赶速度，但如果目标节点已有损坏数据块、或同步源本身 oplog 不完整，rs.syncFrom() 会静默失败或反复重试却无进展。
实操建议：
- 只能对
SECONDARY或RECOVERING状态节点调用，且必须先rs.slaveOk()；执行后立刻查rs.status().members[n].stateStr确认状态是否变化 - 传参必须是完整 host:port，例如
rs.syncFrom("rs0-node1:27017")，不能只写 hostname 或省略端口 - 如果返回
"ok" : 1但延迟没下降，立即去同步源节点查db.serverStatus().metrics.repl.buffer——若currentQueue长期 >1000，说明它自己也在积压，不适合作为同步源 - 真正可靠的修复方式仍是删
dbpath+ 初始同步；rs.syncFrom()只适合轻微滞后且确认源节点健康的场景
仲裁节点（Arbiter）意外参与投票导致 PRIMARY 切换失败
仲裁节点不存数据，但参与选举。如果它网络分区后又恢复，可能持有过期的 term 或 vote，干扰新 PRIMARY 的选举流程，表现为 PRIMARY 反复降级、SECONDARY 无法升主。
实操建议：
- 用
rs.status()检查所有节点的electionId和lastVote字段，若发现某个节点的lastVote中term明显低于其他节点，说明它投了旧票 - 临时移除仲裁节点：
rs.remove("arbiter-host:27017")，等集群稳定后再加回（rs.addArb({host: "...", priority: 0})） - 确保仲裁节点部署在独立网络区域（比如和 PRIMARY 不在同一机房），避免和数据节点同时失联
- 永远不要给仲裁节点设置
priority > 0或votes > 0以外的属性——它只该有投票权，不该被选为主
dbpath 所在分区只剩不到 10% 空间，MongoDB 会主动拒绝写入 oplog 条目，导致同步链路从源头中断。动手前务必先 df -h。
