副本集Oplog Maxsize

Question

我有两个使用ReplicaSet的数据库(MongoDB3.6.5)，当我在网络中进行拆分时，我强迫二级数据库成为主数据库。

cfg = rs.conf()
cfg.members[0].votes = 0
cfg.members[1].votes = 1
cfg.members[0].priority = 0
cfg.members[1].priority = 1
rs.reconfig(cfg, { force: true })

我已经测试了插入在二级起主要作用时，当返回网络并返回到次要位置时，基础被复制，原始主元等于次主。

现在，我再次拔出网络，在二级计算机上执行了几个操作，这些操作被转换为主计算机，直到Oplog的大小超过maxSize为止。经过一段时间不做操作后，Oplog的大小略有减少。我做了一些更多的操作来增加Oplog的大小值，但是没有像以前那样增长。

我的下一步是返回网络，将次要作为辅助返回，并查看它是否同步。

我想知道这个Oplog是怎么工作的？

Answer 1

我有两个使用ReplicaSet的数据库(MongoDB3.6.5)，当我在网络中进行拆分时，我强迫二级数据库成为主数据库。

强制重新配置只能作为行政上的最后手段。这是一种风险很大的方法，只有两个副本集成员，因为您可以轻松地创建需要大量手工恢复工作的数据挑战。

如果您有一个网络分区，并且无意中将双方重新配置为一个主分区，则必须处理回滚和手动协调冲突写入。最糟糕的情况是，对于oplogs来说，有足够多的独立写操作使其不再有共同点:您必须选择一个成员作为主成员，然后再对另一个成员进行重新同步。

现在，我再次拔出网络，在二级计算机上执行了几个操作，这些操作被转换为主计算机，直到Oplog的大小超过maxSize为止。经过一段时间不做操作后，Oplog的大小略有减少。我做了一些更多的操作来增加Oplog的大小值，但是没有像以前那样增长。

复制oplog是一个系统封顶收藏，它的实现因底层MongoDB存储引擎和MongoDB服务器的版本而有所不同。从概念上讲，有上限的集合是按插入顺序维护的，最大大小以字节或文档为单位。您可以认为这类似于循环缓冲区:一旦有上限的集合达到其最大大小，存储引擎将根据插入顺序删除或覆盖最古老的文档。

oplog的上限集合实现有一些额外的细微差别(与标准的上限集合相比)，以提高复制用例的性能。WiredTiger ( MongoDB 3.2+中的默认存储引擎)不会为oplog预先分配全部空间，因此该集合将不断增长，直到接近最大oplog大小为止。WiredTiger有一个后台线程，该线程定期从oplog.rs集合中删除一批最老的条目，因此磁盘上的集合的大小预计会随总体写活动的不同而波动。