节点进入rollback状态的根本原因是副本集发生“双主”或“分叉写入”：原主故障前未同步的写操作与新主写入冲突，恢复后需回退至共同时间点；典型诱因是网络分区而非单纯宕机。
为什么节点会进入 ROLLBACK 状态
根本原因是副本集发生了“双主”或“分叉写入”：原主节点在故障前执行了写操作，但这些操作还没来得及同步到多数成员，它就掉线了；其他节点选出新主并继续写入。当老主恢复并以从节点身份重新加入时，它的最新数据比新主“新”，但又不被承认——于是必须回退到双方都认可的共同时间点（common point），这个过程就触发 ROLLBACK 状态。
- 典型诱因是网络分区（比如原主被隔离但仍在接受写请求），而非单纯宕机
- 使用默认写关注
{w: 1}会显著提高回滚概率；改用{w: "majority"}可大幅降低风险 - 从 MongoDB 4.2 起，进入
ROLLBACK状态时，所有用户操作会被立即终止，不会卡在半途
rollback/ 目录里的 BSON 文件怎么读
回滚数据默认保存在 dbPath/rollback/ 下，路径形如 rollback/<db>.<collection>/removed.<timestamp>.bson</timestamp></collection></db>。这不是日志，而是被撤销的完整文档快照，可用于人工核对或选择性恢复。
- 用
bsondump工具直接解析：bsondump /var/lib/mongodb/rollback/test.users/removed.20260315T123456.bson - 注意：
bsondump输出的是原始 BSON 解码结果，不含 _id 类型信息，需结合集合 schema 判断字段含义 - 不要直接修改或删除这些文件——MongoDB 启动时若检测到未处理的 rollback 文件，可能拒绝启动或强制进入维护模式
回滚失败或卡在 ROLLBACK 状态怎么办
常见于回滚量过大（尤其 ≤3.6 版本受 300MB 限制）、oplog 断层、或同步源不可达。此时节点无法自动完成回滚，会一直停在 ROLLBACK 状态，也不参与选举或读写。
- 先检查
rs.status()输出中该成员的syncSourceHost是否有效；无效则手动指定：rs.syncFrom("host:port") - 确认 oplog 是否足够长：用
db.getSiblingDB("local").oplog.rs.stats()查看maxSize和size，避免因 oplog 被覆盖导致找不到 common point - 若回滚数据超限（如 400MB），且无法扩容 oplog，只能删掉
dbPath并触发初始同步——但这是最后手段，意味着丢弃本地所有数据
哪些操作无法被自动回滚
MongoDB 的回滚机制基于 oplog 反向执行 undo 操作，但并非所有操作都有可逆语义。遇到这类操作时，系统会跳过 undo，转而尝试从同步源重新拉取（refetch）或重建元数据。
- 显式删除类操作：
delete、dropCollection、dropDatabase—— oplog 不记录被删内容，无法还原，只能 refetch 文档或 resync 元数据 - 某些原子更新（如
$inc在并发下）可能产生不可逆偏移，回滚后数值未必精确一致 -
createIndex回滚后会删索引，但background: true创建的索引可能残留部分状态，需人工检查system.indexes
回滚不是事务回滚，它不保证应用层逻辑一致性。真正关键的数据变更，得靠应用层幂等设计+写关注策略兜底。
