一边搭建一边理解MongoDB副本集（副本集回滚）

当先前的主节点故障后重新加入副本集时会回滚恢复写操作。只有在主节点接受了写请求并且从节点没有复制前主节点就故障的时候才需要回滚。当主节点作为从节点重新加入副本集，他恢复或回滚他的写操作来与其他成员保持数据库一致性。

MongoDB尽力避免回滚，这种情况很少见。当回滚确实发生了，那多数是因为网络分区。没有跟上先前主节点操作的从节点，增加了回滚的大小和影响。

如果写操作已经在主节点故障前被其他副本集成员复制，并且这个节点仍然在大部分的副本集成员之中，回滚就不会发生。

收集回滚数据

当回滚确实发生了，MongoDB把回滚数据写入数据库的dbPath的rollback文件夹下的BSON文件中。回滚文件名如下形式：

<database>. <collection>. <timestamp>.bson

例如:

records.accounts.2011-05-09T18-10-04.0.bson

可以用bsondump读取回滚文件的内容。基于该内容和他们应用的了解，管理员可以决定下一步行动。

避免副本集回滚

对于副本集，默认的写关注{w:1}的·仅提供了主节点写操作的确认。使用默认的写关注，数据就有可能在在写操作还没被其他任何从节点复制前主节点就故障了的情况下需要回滚。

为了防止已经给客户端确认的数据回滚，确保所有投票成员启用journaling同时使用w:majority写关注来保证写操作已经出传播到了副本集的大部分成员，然后在发送确认给客户端。

如果writeConcernMajorityJournalDefault设置为false,MongoDB将不会等待w: “majority”确认写入之前写入是持久的。因此，“多数”写操作可能在副本集成员丢失的情况下回滚。

NOTE
无关写关注，使用local(默认)读关注，其他客户端可以在写操作通知写入的客户端之前看到写入操作的结果。
使用local(默认)读关注的客户端可能读取到随后会回滚的数据。、

回滚的限制

一个mongod实例不会回滚超过300m的数据，如果你的系统必须回滚超过300m数据，你必须手动干预来恢复数据。如果出现这种情况，下面一行会显示在你的mongod日志中:

[replica set sync] replSet syncThread: 13410 replSet too much data to roll back

在这种情况下，直接保存数据或强制成员执行初始同步。要强制初始同步，请从集合中”当前“成员同步，通过删除需要回滚较大数据成员的dbPath目录内容。