MongoDB 副本集在主节点异常宕机、网络分区或执行主从切换后，旧主节点上未复制到多数派的写入并不会自动同步给新主节点，而是会进入 rollback 流程，被回滚并保存到本地文件中。理解这一机制对保障数据安全和故障恢复非常关键。
回滚的本质是处理 oplog 分叉：当旧主节点重新加入集群时，会对比自己与新主节点的 oplog，找到公共提交点，将该点之后独有的操作撤销。被撤销的数据不会直接删除，而是写入 rollback 目录，以便人工恢复。这种设计保证了副本集最终一致性，但也要求使用者明确哪些写入可能受到影响。
一、rollback 的触发条件与执行原理
MongoDB 副本集的写入默认采用异步复制，主节点写入后会向从节点复制 oplog 条目。只有写入被复制到多数节点并应用后，才认为达到多数派提交。若主节点在写入仅复制给少数节点时发生宕机或失去多数连通性，集群会选举新主节点。旧主节点重新加入时，可能会发现自己与当前多数派 oplog 存在分叉，也就是包含了一些新主节点没有的操作，于是触发 rollback。
触发 rollback 需要同时满足以下条件：旧主节点在崩溃前接受了写入操作；这些操作在崩溃前未复制到多数派；旧主节点重新加入副本集时，需要追平新主节点的 oplog。MongoDB 会对比新旧主节点的 oplog 记录，找到公共的 oplog 时间点，将该时间点之后旧主节点独有的写入回滚。回滚操作只会撤销数据，不会删除 oplog 历史，回滚掉的写入会写入独立文件。
从 4.0 版本开始，MongoDB 增加了可重试写入和事务机制，但 rollback 仍然是副本集故障恢复的重要组成部分。理解 oplog 分叉、term 与 lastCommittedOpTime 等概念，有助于判断某次写入是否可能被回滚。
二、回滚文件生成机制与手动恢复
当发生 rollback 时，被撤销的文档会保存在数据目录下的 rollback 子目录中。该目录内包含以集合命名的 BSON 文件，以及一个 rollbackTime 记录文件。例如数据目录为 /data/db 时，文件路径可能为 /data/db/rollback/records.bson。每个集合对应一个 BSON 文件，记录被回滚前的完整文档状态。4.0 之后拆分更细，针对每个集合的 UUID 创建子目录。
恢复回滚数据没有内置的一键自动化命令，一般使用 mongorestore 加载这些 BSON 文件。需要注意：如果集群已经继续写入，直接恢复到当前集合可能造成冲突或覆盖新数据。推荐做法是先将回滚文件恢复到不同命名空间，再根据业务逻辑进行合并。以下是使用 mongorestore 恢复示例：
// 将回滚文件恢复到临时数据库 rollback_recovery mongorestore --db rollback_recovery --collection records /data/db/rollback/records.bson
上述命令会把回滚掉的文档恢复到名为 rollback_recovery 的数据库下的 records 集合。恢复后可以对比当前集合，确定哪些数据需要重新插入。如果回滚文件较多，也可以编写脚本遍历 rollback 目录，使用 BSON 解析工具逐条提取。
部分开发者和运维人员还会启用 enableMajorityReadConcern 参数或使用 writeConcern: { w: "majority" } 来降低回滚风险，但即便使用 majority 写入确认，主节点崩溃后仍可能因为读取到旧 committed 状态而出现少量回滚。因此保留回滚文件并定期演练恢复流程很有必要。
三、避免触发 rollback 的配置与最佳实践
降低回滚概率主要从写入确认级别、读关注级别以及集群运维策略三方面入手。write concern 中的 w 参数决定写入需要复制到多少个节点才返回成功。默认值在 MongoDB 4.4 之后为 w: 1，这表示主节点本地写入即可确认，一旦主节点崩溃，未复制的数据就可能回滚。使用 { w: "majority", j: true } 可以要求写入被多数派确认并写入日志，显著降低回滚概率。
在驱动程序或 Mongo shell 中设置全局 write concern 的方法如下：
// 在 Mongo shell 中为单个集合设置 write concern
db.orders.insertOne(
{ item: "mouse", qty: 100 },
{ writeConcern: { w: "majority", wtimeout: 5000 } }
);
read concern 同样重要。如果应用从从节点读取数据，使用 { readConcern: { level: "majority" } } 可以避免读到尚未被多数派确认、将来可能被回滚的数据。对于强一致场景，建议将读操作路由到主节点并配合 majority 读关注。
集群运维策略包括：不要强制 kill -9 主节点进程；执行主从切换前先检查副本集健康状态；网络分区时避免在旧主节点继续写入；对重要的数据修改操作使用事务或可重试写入。MongoDB 4.2 引入的可重试写入可以自动重试一次写入而不会造成重复插入，但需要驱动支持。
四、回滚后的数据核对与故障排查
回滚发生后，最直接的排查入口是 mongod 日志。日志中会包含 rollback 标记、回滚集合数量和 oplog 位置信息。例如出现 rollback 字样、rollback file 路径等。通过日志可以快速确认回滚发生的时间点以及涉及的集合。
如果回滚后应用查询不到预期数据，可以先确认写入时是否收到了确认响应。如果客户端未收到写入成功确认，则不能认为数据已持久化。对于已确认的写入，可以到旧节点数据目录下查看 rollback 文件夹，必要时恢复。还可以通过 db.printReplicationInfo() 查看 oplog 时间窗口，判断旧操作是否已被覆盖。
// 查看当前副本集状态和各节点信息
rs.status().members.forEach(m => {
print(m.name + " : " + m.stateStr + " : " + m.health);
});
排查时还需要关注是否存在网络抖动、磁盘 I/O 延迟、oplog 过小导致的追平失败等问题。oplog 太小会使新节点无法追平历史操作，进而触发全量同步，而不是 rollback。若全量同步与 rollback 同时出现，说明副本集健康状态已经严重受损，需要优先恢复网络和节点状态。
最后，不要因为 rollback 文件存在就认为数据一定完整。回滚文件只包含旧主节点独有的写入，不包含被覆盖的中间状态。因此对于关键业务，除了 write concern 和 read concern，还应该配合备份、变更数据捕获或应用层审计，形成多重保障。
MongoDB rollback数据回滚副本集一致性修改时间：2026-08-20 12:43:56