MongoDB 副本集故障情况描述

副本集有两种类型三种角色

两种类型：

• 主节点（ Primary）类型：数据操作的主要连接点，可读写。
• 次要（辅助、从）节点（ Secondaries）类型：数据冗余备份节点，可以读或选举。

三种角色：

• 主要成员（Primary）：主要接收所有写操作。就是主节点。
• 副本成员（Replicate）：从主节点通过复制操作以维护相同的数据集，即备份数据，不可写操作，但可以读操作（但需要配置）。是默认的一种从节点类型。
• 仲裁者（ Arbiter）：不保留任何数据的副本，只具有投票选举作用。当然也可以将仲裁服务器维护为副本集的一部分，即副本成员同时也可以是仲裁者。也是一种从节点类型。

关于仲裁者的额外说明：

您可以将额外的mongod实例添加到副本集作为仲裁者。 仲裁者不维护数据集。 仲裁者的目的是通过响应其他副本集成员的心跳和选举请求来维护副本集中的仲裁。 因为它们不存储数据集，所以仲裁器可以是提供副本集仲裁功能的好方法，其资源成本比具有数据集的全功能副本集成员更便宜。

如果您的副本集具有偶数个成员，请添加仲裁者以获得主要选举中的“大多数”投票。 仲裁者不需要专用硬件。

仲裁者将永远是仲裁者，而主要人员可能会退出并成为次要人员，而次要人员可能成为选举期间的主要人员。

如果你的副本+主节点的个数是偶数，建议加一个仲裁者，形成奇数，容易满足大多数的投票。

如果你的副本+主节点的个数是奇数，可以不加仲裁者。

情况：一主一副本一仲裁

第一种情况：副本节点故障

主节点和仲裁节点对副本节点的心跳失败。因为主节点还在，因此，没有触发投票选举。

如果此时，在主节点写入数据。再启动从节点，会发现，主节点写入的数据，会自动同步给从节点。

此时：不影响正常使用

第二种情况：主节点故障

从节点和仲裁节点对主节点的心跳失败，当失败超过10秒，此时因为没有主节点了，会自动发起投票。

而副本节点只有一台，因此，候选人只有一个就是副本节点，开始投票。

仲裁节点向副本节点投了一票，副本节点本身自带一票，因此共两票，超过了“大多数”

27019是仲裁节点，没有选举权，27018不向其投票，其票数是0.

最终结果，27018成为主节点。具备读写功能。

再启动 27017主节点，发现27017变成了从节点，27018仍保持主节点。

登录27017节点，发现是从节点了，数据自动从27018同步。

此时：不影响正常使用

第三种情况：仲裁节点故障

主节点和副本节点对仲裁节点的心跳失败。因为主节点还在，因此，没有触发投票选举。

此时：不影响正常使用

第四种情况：仲裁节点和主节点故障

副本集中没有主节点了，导致此时，副本集是只读状态，无法写入。

因为27017的票数，没有获得大多数，即没有大于等于2，它只有默认的一票（优先级是1）

如果要触发选举，随便加入一个成员即可。

• 如果只加入 27019仲裁节点成员，则主节点一定是27017，因为没得选了，仲裁节点不参与选举，但参与投票。
• 如果只加入 27018节点，会发起选举。因为27017和27018都是两票，则按照谁数据新，谁当主节点。

此时：影响正常使用，需要处理

第五种情况：仲裁节点和从节点故障

10秒后，27017主节点自动降级为副本节点。（服务降级）

副本集不可写数据了，已经故障了。

此时：影响正常使用，需要处理

第六种情况：主节点和从节点故障

此时：影响正常使用，需要处理