节点重启后为SECONDARY而非PRIMARY，最常见原因是未以副本集模式启动，即启动时缺少--replSet参数或配置文件中未设置replication.replSetName，导致节点实际运行在standalone模式，无法参与选举和同步。
重启后节点直接变成 SECONDARY，不是 PRIMARY？先看启动时有没有带 --replSet
副本集节点启动后进不了 PRIMARY 状态，最常见原因是根本没以副本集模式启动。MongoDB 启动时不加 --replSet 参数（或配置文件里没配 replication.replSetName），即使后续执行 rs.initiate()，该节点也只会是 standalone 模式，rs.status() 里看不到其他成员，状态永远是 STARTUP 或 PRIMARY（但只是伪 PRIMARY，不参与选举、不同步数据）。
实操建议：
- 检查进程启动命令：运行
ps aux | grep mongod，确认含--replSet xxx；Linux systemd 用户查systemctl cat mongod看ExecStart行 - 配置文件方式：确保
/etc/mongod.conf中有完整段落：replication: replSetName: "myRepl"
- 改完必须重启 mongod，
mongod --shutdown后再启动，仅 reload 配置无效
rs.status() 显示 stateStr 是 SECONDARY，但 optimeDate 落后太多？同步位点可能卡在旧时间戳
节点启动后能加入副本集、状态是 SECONDARY，不代表它在正常同步。关键要看 optimeDate 是否持续更新。如果这个时间戳几小时不动，说明同步源选错了，或者本地 oplog 断档——即本地最后一条 oplog 时间早于所有可用 sync source 的最早 oplog 时间，报错典型是 "We are too stale to use candidate as a sync source"。
实操建议：
- 用
rs.status().members[n].optimeDate对比所有节点，找出最老的那个（注意时区，统一用 UTC） - 检查该节点的
lastHeartbeatMessage字段，常含真实原因，比如"Our last fetch was too old"或"Not enough disk space" - 不要指望自动恢复：一旦进入这种 stale 状态，MongoDB 不会自己换源重试，必须人工干预
删 dbPath 前忘了清 local.replset.minvalid？重启后立刻卡在 RECOVERING
很多操作者删了 dbPath 却仍卡在 RECOVERING，是因为没清理 local 数据库里的元数据。其中 local.replset.minvalid 里的 _initialSyncFlag: true 是个“脏标记”——只要它存在，mongod 启动就会跳过初始同步流程，直接尝试追 oplog，而此时本地 oplog 是空的，必然失败并卡住。
实操建议：
- 删
dbPath必须是**整个目录清空**，不能只删data子目录，local目录也在里面 - 如果误删不彻底，启动后进 shell 执行
use local→db.minvalid.remove({})（仅限刚启动、尚未写入任何数据时） - 别碰
local.oplog.rs手动插入时间戳：该集合是 capped collection，强行写入易损坏结构
为什么 rs.stepDown() 后 PRIMARY 变成 SECONDARY，但新 PRIMARY 没选出来？选举条件没满足
执行 rs.stepDown() 后原 PRIMARY 进入 SECONDARY，但整个副本集长期没新 PRIMARY，通常不是 bug，而是选举失败。MongoDB 要求多数派（majority）节点在线且可通信才能完成选举。例如 3 节点集群挂掉 1 个，剩下 2 个可以选主；但如果是 4 节点挂掉 2 个，只剩 2 个——2 不够 4/2+1=3，无法达成多数，全部卡在 SECONDARY 或 STARTUP2。
实操建议：
- 运行
rs.status().members.map(m => m.stateStr)，数一下PRIMARY和SECONDARY总数，确认是否满足 majority（n/2 + 1 向上取整） - 检查
members[n].health是否全为 1，lastHeartbeat时间是否在 10 秒内 - 仲裁节点（
arbiterOnly: true）不存数据，但计入多数派计算——该开就得开，别为了省资源关掉
stateStr 是 SECONDARY 就以为“没问题”，后面延迟越积越大，直到应用读到脏数据或超时。 
