MongoDB:当Primary失败时



我想了解MongoDB在Primary永久或暂时故障,或在网络级别与副本集的其他部分分离的情况下,为数据的持久性提供了什么保证(如果有的话(。

我理解w:1写作关注会发生什么。我理解写日记的作用。

我不明白MongoDB是如何在选择新的主数据库时决定保留哪些写操作和丢弃哪些写操作的。在4节点(+仲裁器(集群中,N1为主,N2、N3、N4为辅,在这种情况下:

  1. {w:多数,j:真}写入命中Primary
  2. 第二次民意调查的变化,主要等待多数人确认
  3. N2确认了该变化
  4. N3已经接收到该更改并且正在应用该更改
  5. 初级下降
  6. N3无法向Primary确认其已应用更改
  7. 选举是被迫的

问题:

  • 选举结束后,是否可以写入
  • 哪个节点将成为新的主节点重要吗
  • 如果步骤#4没有发生,结果是否不同
  • 如果Primary收到N3的确认,结果是否不同
  • 如果Primary已经确认写入,而N2复制了写入已被多数人确认的事实,结果是否不同
  • 如果N2和N3都复制了多数人确认写入的事实,结果是否不同

第一个背景:

mongodb副本集使用操作日志进行复制。主日志中的每次写入都会附加到操作日志中。

每个辅助节点都会向其同步源查询oplog条目,并批量检索和应用它们。

Oplog条目是幂等的,必须按顺序应用。

在将条目写入操作日志之前,首先将它们写入日志。

如果节点在应用批处理时崩溃,则可以安全地从日志中重播整个批处理,因为每个条目都是幂等的。

成员相互报告他们应用的最新oplog事件的标识符。

由于必须按顺序应用oplog事件,这意味着每个节点在报告的条目之前应用了所有条目,此后没有应用任何条目。

在5个节点的复制集中,大多数是3个节点。在大多数节点报告其操作日志已达到或超过添加写入的点之前,主节点不会向客户端/应用程序确认w:majority写入已完成。

副本集中的每个节点都监视其他每个成员。

如果主要节点意识到它无法与大多数投票节点通信,它将降级为次要节点。

如果辅助设备在几秒钟内(默认为10秒(没有与主设备进行任何通信,它将要求进行选举。

要求选举的节点将征求每个副本集成员的投票。

每个成员通常会投票";是";,他们可以投票的几个原因是";否";是:

  • 候选节点的最新oplog条目不等于或比其他节点更新
  • 该节点与优先级等于或高于候选节点的主节点进行当前通信

如果候选节点获得足够的"是"投票,以构成副本集中的大多数投票节点,则它将转换为主要节点并接受写入。

每次选择都会增加副本集的term值。如果主节点从其他节点中的一个节点接收到包含比其当选时更高术语的检测信号或其他消息,则它会立即降级到辅助节点。

在您的场景中:

{w:mority,j:true}write命中Primary。

主要将:

  • 将写操作应用于数据集的本地副本
  • 将操作写入日志
  • 将操作写入操作日志

假设主操作日志现在包含:

操作
时间
T1 创建集合
T2 创建索引
T3 插入文档1
T4 插入文档2
T5 更新文档1
T6 插入文档3

相关内容

  • 没有找到相关文章

最新更新