mongodb - 多数关注的新成员添加期间二级数据过时

Question

给定一个由 1 个主要 + 1 个辅助 + 1 个仲裁器组成的基本副本集，启用了 mongo 4.0 和多数，我们遇到了一个我们还无法解释的奇怪问题

我们想向副本集添加一个新的辅助节点。所以我们启动了一个新的VM，安装并配置了mongod，然后将节点添加到replicaSet。新成员以 STARTED2 状态出现，并正在与现有集群同步。到目前为止，一切都很好。

但是我们注意到了一些事情：我们从辅助节点（readPref：secondaryPreferred，readConcern：majority）读取的应用程序之一正在读取陈旧数据（从同步开始之日起）。看着rs.status()，确实lastCommittedOpTime是卡在了过去。正如预期的那样，主节点的wiredtiger缓存使用量开始增加，达到15~20%的区域，并开始减慢主节点的速度。

我们最终通过在同步时将成员声明为隐藏来解决问题，但是：为什么会发生这种情况？

我的理解是，在大多数成员承认所述数据之前，数据不会提交到“主要”区域。但是对于 3 个数据成员（主要 + 次要 + 新次要），大多数应该已经与现有成员会面。为什么添加新成员会导致这种行为？

标签： mongodbreplicasetwiredtiger

Answer 1

“多数”是指多数投票节点。

在原始集群中，Primary、Secondary 和 Arbiter 各有 1 票，因此多数为 2。一旦写入主节点和辅助节点，写入就被视为多数已提交。

添加新节点后，有 4 个投票，Primary、原始 Secondary、新 Secondary、Arbiter。

这意味着 2 不再是多数，而只是一半。因此，为了被认为是多数提交，它必须被写入 3 个投票节点，即主节点和两个辅助节点。

每个复制的节点都以相同的顺序保存操作日志，并记录已知已提交给大多数节点的最新操作。这称为多数提交点。任何请求多数读取关注的读取都将使用截至多数提交点的数据快照。

一旦添加了新节点，大多数写入将无法完成，直到它完成初始同步并开始应用 oplog。在那之前，所有多数读取都将是最近的多数提交点，就在添加该节点之前。

简单修复：删除仲裁器。这将使集群返回到 3 个投票节点，并且大多数写入将能够在只有主节点和一个辅助节点确认写入的情况下完成。