副本集成员状态
副本集的每个成员都有一个状态。
数值 | 名称 | 状态描述 |
---|---|---|
0 | 还不是任何设立的活动成员。所有成员均会以此状态启动。 在 | |
1 | 处于主节点状态的成员是唯一可以接受写入操作的成员。有资格投票。 | |
2 | 处于从节点状态的成员正在复制数据存储。有资格投票。 | |
3 | ||
5 | 节点正在运行初始同步。有资格投票,但新添加到副本集时除外。 | |
6 | 从集合中的另一个成员来看,该成员的状态尚不清楚。 | |
7 | 仲裁节点不复制数据,其存在的唯一目的是参与选举。有资格投票。 | |
8 | 从集合的另一个成员来看,该成员是无法访问的。 | |
9 | ||
10 | 此成员曾经在副本集中,但随后被删除。 |
状态
核心状态
PRIMARY
处于 状态的成员接受写入操作。一个副本集一次最多有一个主节点 (primary
PRIMARY
node in the replica set)节点。 []1SECONDARY
成员在选举后成为主节点 (primaryPRIMARY
node in the replica set)节点。处于 状态的成员有资格投票。
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
状态并需要手动干预。
错误状态
处于任何错误状态的成员都不能投票。
UNKNOWN
从未向副本集传达过状态信息的成员均处于
UNKNOWN
状态。
DOWN
与副本集失去连接的成员会被该集合的其余成员视为
DOWN
。
[1] | 在某些情况下,副本集中的两个节点可能会暂时认为它们是主节点,但最多只能有其中一个节点能够完成具有{ w:
"majority" } 写入关注的写入操作。可以完成{ w: "majority" } 写入操作的节点是当前主节点,另一个节点是尚未识别其降级(通常是由于网络分区)的前主节点。发生这种情况时,尽管已请求读取偏好primary ,但连接到前主节点的客户端可能会观察到过时数据,并且对前主节点的新写入操作最终将回滚。 |