副本集成员状态

核心状态

PRIMARY

处于 PRIMARY 状态的成员接受写操作。一个副本集在同一时间最多只有一个主节点。[1] 一个 SECONDARY 成员在 选举 后成为主节点。处于 PRIMARY 状态的成员有投票资格。

SECONDARY

处于 SECONDARY 状态的成员复制主节点的数据集，并且可以配置为接受读操作。第二级成员有资格参加选举，并且如果主节点不可用，可能被选为主节点。

仲裁者

处于 仲裁者 状态的成员不复制数据或不接受写操作。它们有投票资格，仅存在于选举中打破僵局。只有在该集合原本有偶数个投票成员且可能遭受平局选举的情况下，副本集才应有一个处于 仲裁者 状态的成员。在任何副本集中，最多只能配置一个仲裁者。关于使用仲裁者的考虑因素，请参阅副本集仲裁者。

有关核心状态的更多信息，请参阅副本集成员。

其他状态

启动

副本集中的每个成员都以 启动 状态启动。然后 mongod 加载该成员的副本集配置，并将成员的状态转换为 启动2 或 仲裁者。处于 启动 状态的成员无权投票，因为它们还不是任何副本集的认可成员。

启动2

已更改在版本中5.0.

每个承载数据的副本集成员在 启动2 状态中，一旦 mongod 加载了该成员的配置。

成员随后决定是否进行初始同步。如果成员开始初始同步，则该成员将保持 启动2 状态，直到所有数据都已复制并且所有索引都已构建。之后，该成员的状态将转换为 恢复中。

在STARTUP2阶段新添加的成员无权投票，并且在初始同步过程中不能被选举。在MongoDB 5.0之前，STARTUP2阶段的成员有权投票。

RECOVERING

当副本集成员尚未准备好接受读取时，它会进入RECOVERING状态。在正常操作过程中可能会出现RECOVERING状态，但这并不一定表示存在错误条件。处于RECOVERING状态的成员有资格参加选举，但不能进入PRIMARY状态。

成员在复制足够的数据以确保客户端读取数据的一致性视图后，从RECOVERING状态过渡到SECONDARY状态。RECOVERING状态和SECONDARY状态之间的唯一区别是，RECOVERING状态禁止客户端读取，而SECONDARY状态允许它们。SECONDARY状态并不保证与主节点的数据陈旧性。

由于过载，一个次要成员可能落后于副本集的其他成员，以至于可能需要与集的其他部分同步。在这种情况下，该成员将进入RECOVERING状态并需要手动干预。

ROLLBACK

每当复制集在选举中替换主节点时，旧主节点可能包含未复制到辅助节点的文档。在这种情况下，旧主节点将撤销这些写入。在回滚过程中，成员将处于ROLLBACK状态。处于ROLLBACK状态的成员有资格参与选举。

从版本4.2开始，MongoDB在成员进入ROLLBACK状态时，会终止所有进行中的用户操作。

错误状态

处于任何错误状态的成员不能投票。

UNKNOWN

从未向副本集发送状态信息的成员处于 UNKNOWN 状态。

DOWN

失去与副本集连接的成员被视为副本集中剩余成员的 DOWN。

REMOVED

从副本集中移除的成员进入 REMOVED 状态。当成员进入 REMOVED 状态时，日志将使用 replSet REMOVED 消息条目标记此事件。