副本集故障转移期间的回滚

在本页面

当成员在failover之后重新加入其replica set时，回滚将还原对前一个primary的写操作。仅当主节点在降级之前接受了secondaries没有成功复制的写入操作时，才需要回滚。当主数据库作为辅助数据库重新加入集合时，它将还原或“回滚”其写操作，以保持数据库与其他成员的一致性。

MongoDB 尝试避免回滚，这种回滚很少见。确实发生回滚时，通常是网络分区的结果。不能跟上前一个主节点的操作吞吐量的辅助节点会增加回滚的大小和影响。

如果写操作复制到主副本降级之前的副本集的另一个成员，并且*如果该成员仍然对大多数副本集可用并且可以访问，则不会发生回滚。

收集回滚数据

当确实发生回滚时，MongoDB 会将回滚数据写入数据库dbPath目录下rollback/文件夹中的BSON文件中。回滚文件的名称具有以下形式：

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

For example:

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

要读取回滚文件的内容，请使用bsondump。根据内容及其应用程序的知识，Management 员可以决定下一步要采取的行动。

对于副本集，默认的写关注\ {w: 1}仅提供对主副本上写操作的确认。对于默认的写入问题，如果在写入操作已复制到任何辅助数据库之前主数据库降级，数据可能会回滚。

为防止回滚已确认给 Client 端的数据，请在启用日记功能的情况下运行所有有表决权的成员，并使用w：多数写关注来确保写入操作传播到大多数副本集节点，然后返回给发行方 Client 端确认。

在writeConcernMajorityJournalDefault设置为false的情况下，MongoDB 在确认写入之前不会 awaitw: "majority"写入磁盘日志上。这样，如果给定副本集中的大多数节点发生瞬时丢失(例如崩溃和重新启动)，则majority写操作可能会回滚。

Note

不管write concern为何，使用"local"或"available"的其他 Client 端 readConcern 都可以在向发布 Client 端确认写入操作之前看到写入操作的结果。
使用"local"或"available" readConcern 的 Client 端可以读取随后可能是rolled back的数据。

mongod实例回滚的数据不会超过 300 兆字节。如果系统必须回滚超过 300 MB，则必须手动进行干预以恢复数据。如果是这种情况，您的mongod日志中将显示以下行：

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

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