当成员在故障转移后重新加入其副本集时,回滚将还原以前的主数据库上的写操作。回滚是必要的只有一次接受了写操作的次级已没有 成功复制之前的一次阶梯状下降。当主数据库作为辅助数据库重新加入集合时,它将还原或“回滚”其写入操作,以保持数据库与其他成员的一致性。
MongoDB尝试避免回滚,这种回滚很少见。确实发生回滚时,通常是网络分区的结果。不能跟上前一个主服务器上的操作吞吐量的辅助服务器会增加回滚的大小和影响。
如果在主数据库降级之前将写操作复制到副本集的另一个成员,并且该成员仍然对大多数副本集可用且可访问,则不会发生回滚。
从版本4.0开始,MongoDB添加参数
createRollbackDataFiles
来控制是否在回滚期间创建回滚文件。
对于副本集,默认写关注点{w:1}仅提供对主副本上写操作的确认。对于默认的写入问题,如果在写入操作已复制到任何辅助数据库之前主数据库降级,数据可能会回滚。这包括在
多文档事务中使用写关注提交的数据。"w: 1"
majority
¶为防止回滚已确认给客户端的数据,请在启用日记功能的情况下运行所有有表决权的成员,并使用w:多数写入问题来确保写入操作传播到多数副本集节点,然后返回给发行方客户端确认。
随着writeConcernMajorityJournalDefault
设置为false
,MongoDB的不等待
写入承认写之前被写入到磁盘上的日志。这样,在给定副本集中的大多数节点发生瞬时丢失(例如崩溃和重新启动)的情况下,写操作可能会回滚。w: "majority"
majority
"local"
或"available"
读关注的客户端都可以在向发布客户端确认写操作之前看到写操作的结果。"local"
或"available"
读取关注点的客户端可以读取数据,这些数据随后可能会在副本集故障转移期间回滚。对于多文档事务中的操作,在提交事务时,将保存在事务中进行的所有数据更改,并在事务外部可见。也就是说,一个事务在回滚其他事务时将不会提交其某些更改。
在提交事务之前,在事务外部看不到在事务中进行的数据更改。
但是,当一个事务写入多个分片时,并非所有外部读取操作都需要等待已提交事务的结果在所有分片上可见。例如,如果提交了一个事务,并且在分片A上可以看到写1,但是在分片B上仍然看不到写2,则外部读处于读关注状态
"local"
可以读取写1的结果而看不到写2。
"4.2"
,MongoDB等待任何正在进行的
索引构建完成,然后再开始回滚。"4.0"
,MongoDB 在开始回滚之前会等待任何正在进行的后台
索引构建完成。有关索引构建过程的更多信息,请参见填充集合上的索引构建 。
在版本4.0中更改。
从版本4.0开始,MongoDB对可回滚的数据量没有限制。
在以前的版本中,一个mongod
实例将不会回滚超过300兆字节的数据,并且如果需要回滚超过300兆字节的数据,则需要手动干预。
从版本4.0开始,回滚时间限制默认为24小时,可以使用以下参数进行配置
rollbackTimeLimitSecs
:
在MongoDB 3.6和更早版本中,回滚时间限制是不可配置的,并且设置为30分钟。