副本集成员状态
副本集的每个成员都有一个状态。
数值 | 名称 | 状态描述 |
---|---|---|
0 | 还不是任何设立的活动成员。 所有成员均会以此状态启动。 在 | |
1 | 处于主节点状态的成员是唯一可以接受写入操作的成员。有资格投票。 | |
2 | 处于从节点状态的成员正在复制数据存储。有资格投票。 | |
3 | ||
5 | 节点正在运行初始同步。有资格投票,但新添加到副本集时除外。 | |
6 | 从集合中的另一个成员来看,该成员的状态尚不清楚。 | |
7 | 仲裁节点不复制数据,其存在的唯一目的是参与选举。有资格投票。 | |
8 | 从集合的另一个成员来看,该成员是无法访问的。 | |
9 | ||
10 | 此成员曾经在副本集中,但随后被删除。 |
状态
核心状态
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 ,但连接到前主节点的客户端可能会观察到过时数据,并且对前主节点的新写入操作最终将回滚。 |