MongoDB WriteConcern 对复制的影响

Question

一般来说，MongoDB 会根据写入操作的数量、时间和其他因素，通过将 oplog 从主节点传送到辅助节点来异步地从主节点复制到辅助节点。

在描述 WriteConcern 选项时，MongoDB documentation 声明“......主要等待直到所需数量的辅助节点在返回写入关注确认之前确认写入”。这似乎表明“w:1”以外的 WriteConcern 将以阻塞方式复制到副本集的至少一些成员，从而可能避免日志传送。

我要回答的基本问题是：如果每次写入都使用“多数”的 WriteCocnern，那么 MongoDB 是否必须使用日志传送？换句话说，使用“多数”的 WriteCocnern 是否也控制了复制时间？

我想更好地了解 MongoDB 如何处理“多数”的 WriteConcern。一些明显的选择：

1. Primary 向 每个 Secondary 发送写请求，并阻塞线程直到大多数响应确认 或
2. 主要预选次要首先发送请求并仅向这些次要发送请求，阻塞线程直到所有选择的次要都响应确认 或
3. 比这两个选项更智能

如果使用选项 1，在大多数情况下（假设辅助节点等距放置）所有辅助节点将在写入完成时收到写入操作，并且概率很高（尽管不能保证） 所有次要应用它。如果为 true，则此行为支持写入需要比典型异步复制过程更快地反映在辅助节点上的用例。

显然，“多数”的 WriteConcern 会导致性能损失，但这对于读取操作可能针对辅助节点（例如“最近”的 ReadPreference）并希望获得更多最新数据的特定用例来说可能是可以接受的。

Answer 1

如果每次写入都使用“多数”的 WriteConcern，MongoDB 是否必须使用日志传送？

MongoDB 中的复制使用所谓的oplog。这是主节点（唯一接受写入的节点）上所有操作的记录。

辅助节点不会将 oplog 推送到辅助节点，而是长拉主节点的 oplog。如果允许复制链接（默认），则辅助节点也可以从另一个辅助节点拉取 oplog。因此，从 MongoDB 4.0 开始，您发布的场景 1 和 2 并不是 MongoDB 复制的现实。

MongoDB Github wiki 页面中描述了复制过程的详细信息：Replication Internals。

引用有关您问题的相关部分：

如果命令包含写入问题，该命令将阻塞在自己的线程中，直到它生成的 oplog 条目被复制到请求的节点数。主要跟踪次要知道何时返回的最新状态。写入关注点可以指定要等待的节点数或多数。

换句话说，辅助节点不断地向主节点报告它将 oplog 应用到自己的数据集中的程度。由于主节点知道写入发生的时间戳，因此一旦辅助节点应用了该时间戳，它就可以判断写入已传播到该辅助节点。为了满足写入问题，主节点只是等待，直到确定数量的辅助节点应用了写入时间戳。

请注意，只有指定写入关注点的线程在等待此确认。由于这种等待，所有其他线程都不会被阻塞。

关于你的其他问题：

显然，“多数”的 WriteConcern 会导致性能损失，但这对于读取操作可能针对辅助节点（例如“最近”的 ReadPreference）并需要更新数据的特定用例来说可能是可以接受的。

要实现您所描述的，您需要结合读取和写入问题。有关此主题的更多详细信息，请参阅 Causal Consistency and Read and Write Concerns。

写多数通常用于：

• 确保在主节点发生故障时不会回滚写入。
• 确保应用程序写入速度不会太快，以至于副本集的配置硬件无法应对流量；即它可以充当背压机制。
• 结合read concern，为客户提供不同级别的一致性保证。

这些点假定写入多数已被确认并且客户端已收到确认。可能存在多种不同的故障情况（正如预期的需要处理不可靠网络的分布式系统），但这些超出了本次讨论的范围。