副本集成员状态

核心状态

PRIMARY

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

SECONDARY

处于 SECONDARY 状态的成员会复制主节点的数据集，并且可以配置为接受读取操作。从节点有资格在选举中投票，并且如果主节点不可用，则可能会被选入 PRIMARY 状态。

ARBITER

处于 ARBITER 状态的成员不会复制数据，也不接受写入操作。它们有资格投票，且其存在仅出于在选举期间打破平局。如果副本集拥有偶数个有投票权成员，且可能会出现平局选举，副本集则应只拥有处于 ARBITER 状态的成员。在所有副本集中，最多只能配置一个仲裁节点。有关使用仲裁节点时的注意事项，请参阅副本集仲裁节点。

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

其他状态

STARTUP

副本集的每个成员均会以 STARTUP 状态启动。mongod 然后加载该成员的副本集配置，并将该成员的状态转换为 STARTUP2 或 ARBITER。STARTUP 中的成员没有资格投票，因为它们还不是任何副本集的认可成员。

STARTUP2

5.0 版本中的更改。

副本集的每个数据承载成员在 mongod 加载完该成员的配置后立即进入 STARTUP2 状态。

然后，该成员会决定是否进行初始同步。如果某个成员开始初始同步，则该成员将保持 STARTUP2 状态，直到复制完所有数据并建立完所有索引为止。之后，该成员会转换为 RECOVERING。

STARTUP2 中新添加的成员没有资格投票，也无法在初始同步进程中当选。在 MongoDB 5.0 之前，STARTUP2 中的成员有资格投票。

RECOVERING

当副本集的成员未准备好接受读取时，它会进入 RECOVERING 状态。RECOVERING 状态可能会在正常运行时出现，不一定反映错误情况。处于 RECOVERING 状态的成员有资格在选举中投票，但没有资格进入 PRIMARY 状态。

复制了足够的数据后，成员从 RECOVERING 转换为 SECONDARY，以确保客户端读取的数据视图一致。RECOVERING 和 SECONDARY 状态之间唯一的区别是 RECOVERING 禁止客户端读取，而 SECONDARY 允许客户端读取。SECONDARY 状态不能保证数据相对于主节点已过期。

由于过载，从节点可能远远落后于副本集的其他成员，因此可能需要与副本集的其余成员重新同步。发生这种情况时，该成员会进入 RECOVERING 状态并需要手动干预。

ROLLBACK

每当副本集在选举中替换主节点时，旧的主节点可能包含未复制到从节点成员的文档。在这种情况下，旧的主节点成员会恢复这些写入。在回滚过程中，该节点将处于 ROLLBACK 状态。处于 ROLLBACK 状态的节点有资格在选举中投票。

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

错误状态

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

UNKNOWN

从未向副本集传达过状态信息的成员均处于 UNKNOWN 状态。

DOWN

与副本集失去连接的成员会被该集合的其余成员视为 DOWN。

REMOVED

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