副本集回滚根本原因是“双主”或“分叉写入”，典型诱因是网络分区；需通过{w: "majority"}写关注和网络稳定性预防，rollback目录仅用于事后诊断，无法防止故障发生。
副本集发生回滚不是配置能“应对”的问题，而是必须通过写关注策略和网络稳定性来预防；rollback目录只是事后诊断用的，不能靠它防故障。
为什么改createRollbackDataFiles参数没用
这个参数只控制是否把回滚数据存成.bson文件，默认是true。但开启它不会阻止回滚发生，也不会修复不一致——它只是让运维能手动检查丢了多少数据。你看到/rollback/xxx/removed.2026-04-12T04-39-00.0.bson这类路径，说明回滚已经完成了，节点已降级为SECONDARY，此时业务早就感知到写失败或读到脏数据了。
- 回滚触发后，节点立即终止所有用户操作，不会卡在中间状态
- 文件名里的 UUID 是随机生成的，每次回滚都不同，没法提前预测路径
- 用
bsondump读出来的数据没有事务上下文，无法直接重放，只能人工比对
真正该配的不是rollback目录，而是w: "majority"
默认{w: 1}写关注只等主节点落盘就返回成功，一旦主节点宕机前没同步出去，新主选出来后必然分叉——这是回滚最常见原因。改成{w: "majority"}后，写操作必须被多数节点确认才返回，从根源上压缩回滚窗口。
- 三节点副本集：要求至少2个节点写成功（含主）
- 五节点副本集：要求至少3个节点写成功
- 注意：
w: "majority"会增加写延迟，尤其在网络抖动时可能超时 - 搭配
j: true可进一步保证写入磁盘，避免因OS缓存丢失日志
回滚发生时，rs.status()里哪些字段最关键
别只看stateStr是不是ROLLBACK，重点盯这几个字段：
-
optime和lastAppliedWallTime：对比其他成员，看落后多少秒 -
syncSourceHost：当前选的同步源是谁，是否合理（比如不该从隐藏节点拉） -
health：值为0表示节点不可达，可能是网络分区而非宕机 -
votes和priority：低优先级节点如果意外获得投票权，可能干扰选举节奏
如果发现某个节点optime比新主还新，但syncSourceHost为空，基本可以断定它被隔离过，正在等待同步源上线。
超过300MB回滚必须手动干预
MongoDB硬性限制单次自动回滚不超过300MB。一旦日志里出现rollback too large: 321567890 bytes，节点会卡在STARTUP2或RECOVERING状态，拒绝加入集群。
- 此时删掉
dbpath并执行初始同步是最稳妥做法 - 不要试图用
mongorestore导入rollback目录下的bson——它们不是完整快照，只是变更差量 - 若业务不允许停机，可临时将该节点设为
hidden: true、priority: 0，先让它异步追平再切回来
回滚的本质是承认“那段时间的数据不可信”，而不是把它修好。越想绕过这个逻辑去保数据，越容易陷入双主、孤儿文档、应用层幻读这些更难排查的问题。
