doc: 阅读redis cluster voting文档
This commit is contained in:
@@ -239,6 +239,7 @@
|
||||
- [Configuration epoch](#configuration-epoch)
|
||||
- [replica election and promotion](#replica-election-and-promotion)
|
||||
- [Replica Rank](#replica-rank)
|
||||
- [masters reply to replica vote request](#masters-reply-to-replica-vote-request)
|
||||
|
||||
|
||||
# redis
|
||||
@@ -3790,3 +3791,16 @@ DELAY = 500 milliseconds + random delay between 0 and 500 milliseconds + REPLICA
|
||||
- 其向其他节点发送的heartbeat packet被检测为过时,从其他节点接收到UPDATE packet时
|
||||
|
||||
对于其他节点,将会探知到`a new master serving the same slots served by the old master but with greater configEpoch`,并且其他节点会更新configuration。`replicas of the old master`不仅会更新配置,还会`replicate from the new master`。
|
||||
|
||||
#### masters reply to replica vote request
|
||||
在failover的过程中,masters将会以`FAILOVER_AUTH_REQUEST`的形式接收投票请求。
|
||||
|
||||
接收到AUTH_REQUEST之后,如果满足下列条件,那么将会授予选票:
|
||||
- 在给定的epoch范围内,master只能投票一次,并且master会拒绝为older epochs投票
|
||||
- 每个master都拥有一个lastVoteEpoch字段,并且,在auth requst中currentEpoch小于或等于lastVoteEpoch时,会拒绝投票。当master成功投票后,`lastVoteEpoch`将会被更新,并且会存储到磁盘中
|
||||
- 只有当`master of replica`被标记为FAIL时,master才会为replica投票
|
||||
- 当`auth request的currentEpoch`小于master的currentEpoch时,auth request将会被忽略。故而,master的响应中,currentEpoch总是和auth request中的currentEpoch相同。如果相同的replica再次要求投票,需要对currentEpoch进行递增,并且`old delayed reply from the master can not be accepted for the new vote`
|
||||
- 如果master已经投过票,那么在`NODE_TIMEOUT * 2`的时间范围内,master并不会再次针对`同一master的replica`投票
|
||||
- 对master而言,其并不会对`选取最佳副本`做任何尝试。如果replica的master处于FAIL状态,并且master在本epoch内没有针对`master of replica`进行投票,那么直接会授予选票。但是,基于replica发起AUTH REQUEST之前的延迟,最佳的副本最有可能赢得选举,因为其发起请求最早
|
||||
- 如果master拒绝为replica进行投票,那么其并不会向replica发送negative reply,仅仅会无视请求
|
||||
- master不会为
|
||||
Reference in New Issue
Block a user