副本集成员状态

核心状态

PRIMARY

处于 状态的成员接受写入操作。一个副本集一次最多有一个主节点 (primary nodePRIMARY in the replica set)。 []1 SECONDARY成员在选举后成为主节点 (primaryPRIMARY node in the replica set)。处于 状态的成员有资格投票。

SECONDARY

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

ARBITER

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

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

其他状态

STARTUP

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

STARTUP2

在版本5.0中进行了更改。

一旦 完成加载节点的配置，副本集的每个数据承载节点就会进入STARTUP2 mongod状态。

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

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

RECOVERING

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

RECOVERING复制足够多的数据后，成员会从SECONDARY 转换到RECOVERING ，以保证客户端读取的数据视图一致。 和SECONDARY 状态之间的唯一区别是RECOVERING 禁止客户端读取，而SECONDARY 允许客户端读取。 状态不保证有关主节点 (primary node in the replicaSECONDARY set)的数据过时。

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

ROLLBACK

每当副本集在选举中替换主节点 (primary node in the replica set)时，旧的主节点 (primary node in theROLLBACK replica set)可能包含未复制到从从节点(secondary node from replica set)成员的文档。在这种情况下，旧的主节点 (primary node in the replicaROLLBACK set)成员会恢复这些写入。在回滚期间，成员将处于 状态。处于 状态的成员有资格在选举中投票。

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

错误状态

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

UNKNOWN

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

DOWN

与副本集失去连接的成员将被副本设立的其余成员视为DOWN 。

REMOVED

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