强制重配副本集后节点变PRIMARY，须逐个加回并验证writeConcernMajorityJournalDefault与journal启用状态，否则可能因oplog断点错位或journal未启用导致回滚丢数据。
副本集失去多数派（即存活节点数 rs.status() 中将看不到合法的 PRIMARY，所有节点停留在 SECONDARY 或 RECOVERING 状态，写操作会因 w: "majority" 超时或报 NotMaster 失败。这不是“暂时不可用”，而是法定人数失效——必须人工干预，不能等自动恢复。
确认是否真失去多数派
别只看节点数量，要看 rs.status().members 中每个成员的 health: 1 和 stateStr：
-
health: 0的节点不参与法定人数计算，即使进程还在跑 - 若存活且健康节点数为 2（在 5 节点集群中），则实际只有 2/5，
⌊5/2⌋+1 = 3，已低于多数，选举被阻断 - 注意
lastHeartbeatRecv时间戳：如果某个节点的该值停滞在分区发生时刻，说明它已失联，不应计入健康节点
只剩一个健康 SECONDARY 时强制重配升主
当仅剩一个可连通、health: 1 的 SECONDARY，且其他节点全部失联或宕机，必须手动重建法定多数：
- 连上那个唯一存活节点，在
mongoshell 中执行cfg = rs.conf() - 清空
cfg.members，只保留该节点（例如：cfg.members = [cfg.members[2]]） - 确保其
priority >= 1、votes: 1，且hidden: false、arbiterOnly: false - 运行
rs.reconfig(cfg, {force: true})——{force: true}是必须项，否则会因“无法联系多数节点”拒绝执行 - 成功后该节点立即变为
PRIMARY，此时才能用rs.add("host:port")逐个加回恢复中的节点
恢复后必须检查 writeConcernMajorityJournalDefault
脑裂或强制重配后，最容易被忽略的是 journal 配置是否生效——它直接决定回滚时会不会丢数据：
- 查节点启动参数：
db.runCommand({ getCmdLineOpts: 1 })，确认storage.journal.enabled: true - 查副本集全局设置：
db.adminCommand({ getParameter: 1, writeConcernMajorityJournalDefault: 1 }) - 如果返回
"writeConcernMajorityJournalDefault": false，需在所有节点的启动配置中显式设为true并重启，否则哪怕写入了 majority，崩溃后仍可能丢失
多数派恢复不是“加回节点就完事”。真正麻烦的是状态不一致的残留、oplog 断点错位、以及 journal 关闭导致的静默数据丢失——这些都在表面恢复正常后才暴露。
