复制-复制集Oplog


  • 註冊用戶

    复制集Oplog

    Oplog(操作日志)是一个特殊的上限集合,保存所有修改存储在数据库中的数据的操作的滚动记录。 MongoDB在主数据库上应用数据库操作,然后将操作记录在主节点的Oplog上。 然后,从节点在异步过程中复制和应用这些操作。 所有复制集成员都在local.oplog.rs集合中包含Oplog的副本,这允许它们维护数据库的当前状态。

    为了提高复制的效率,复制集中所有节点之间会互相进行检测(通过ping)。每个节点都可以从任何其他节点上获取Oplog。

    Oplog中的每个操作都是幂等的。 也就是说,Oplog中的每一条操作,无论是执行一次还是多次执行,对数据集的影响结果是一样的。

    Oplog大小

    大多数情况下,默认的Oplog大小是足够的。举个例子,如果Oplog的大小是可用空间的5%,且可以存储24小时内的操作,那么从节点就可以在停止复制24小时后仍能追赶上主节点,而不需要重新获取全部数据。然而,大多数复制集中的操作没有那么频繁,Oplog可以存放远不止上述的时间的操作记录。

    在 mongodb 建立Oplog之前,我们可以通过设置 OplogSizeMB 选项来设定其大小。但是,如果已经初始化过复制集,已经建立了Oplog了,我们需要通过 修改Oplog大小 的方式来修改其大小。

    Oplog的大小应随着实际使用压力而增加

    如果我能够对我复制集的工作情况有一个很好地预估,如果可能会出现以下的情况,那么我们就可能需要创建一个比默认大小更大的Oplog。相反的,如果我们的应用主要是读,而写操作很少,那么一个小一点的Oplog就足够了。

    下列情况我们可能需要更大的Oplog:

    1. 同时更新大量的文档。
    Oplog为了保证 幂等性 会将多项更新(multi-updates)转换为一条条单条的操作记录。这就会在数据没有那么多变动的情况下大量的占用oplog空间。
    2. 删除了与插入时相同大小的数据
    如果我们删除了与我们插入时同样多的数据,数据库将不会在硬盘使用情况上有显著提升,但是Oplog的增长情况会显著提升。
    3. 大量In-Place更新
    如果我们会有大量的in-place更新,数据库会记录下大量的操作记录,但此时硬盘中数据量不会有所变化。
    

    Oplog状态

    我们可以通过 rs.printReplicationInfo() 来查看Oplog的状态,包括大小、存储的操作的时间范围。关于Oplog的更多信息可以参考 Check the Size of the Oplog 。

    在各类异常情况下, 从节点Oplog的更新可能落后于主节点一些时间。在从节点上通过 db.getReplicationInfo() 和 db.getReplicationInfo 可以获得现在复制集的状态,也可以知道是否有意外的复制延时。




登录后回复
 

与 萌阔论坛 的连接断开,我们正在尝试重连,请耐心等待