redis sentinel failover

redis sentinel failover过程：以下如无特别情况，均站在sentinel的视角。

发现master处于ODOWN状态（objective down）。

明白哪个sentinel是能start failover的leader，其他sentinel都是observer（选举过程后面会讲，现阶段看主要是runid较低）。

leader选取一个slave，将其提升为master（good slave的标准后面会讲）。

通过命令“slaveof no one”，选取的slave变成master。（leader如何通知它？它如何通知observer？）。

observer发现有slave被提升为master（由命令slave of no one），他们就知道failover开始了，所以slave of no one会被看做failover的开始。

跟之前（已经ODOWN）的master连接的slave会被重新configure（使用slave of），以便开始与新的master进行replication。

每个slave都被重新configure以后，leader会终止failover进程。大家将老master移出各自的table，并开始监控新的master，就像leader所做的那样。

选取leader的算法跟判断master是否为ODOWN的算法一样，主要使用sentinel is-master-down-by-addr命令。它返回各个sentinel在自己的视角上认为的leader（subjective leader），subjective leader由各个sentinel根据以下算法得出：

We remove all the Sentinels that can't failover for configuration (this information is propagated using the Hello Channel to all the Sentinels). （不会翻译）

移除所有处于SDOWN、无法连接、最后一次回复ping请求距离现在至少SENTINEL_INFO_VALIDITY_TIME毫秒的sentinel。

获取剩下的sentinel中runid最小的一个，按字典顺序选出（runid是每个redis实例（不仅是sentinel）的独一无二的身份标识）。

只有满足以下条件后，一个sentinel才能认为自己是objective leader：

它认为自己是个subjective leader。

至少50%+1的sentinel也认为它是个leader（通过回复sentinel is-master-down-by-addr），并且认同它是个leader的sentinel总数要大于等于我们配置的数。

当某个sentinel认为自己是leader之后，再等上个5s+随机长的时间，failover就开始了。等待是因为，如果这段时间里我们检测到了另外一个实例正在将一个slave变成master，我们认为它是正在开始failover的另一个实例，所以它会将自己转为observer。（会不会发生：A和B都在准备start failover，同时A和B都注意到了对方的leader身份，所以A和B都将自己转为observer？）

sentinel rule #11： 一个good slave是满足以下条件的slave：（稍后再翻）。

sentinel rule #12：subjunctive leader是sentinel认为满足以下条件的那个实例：拥有更低的runid（包括自己的），monitoring a given master（此时没有新master，这个是是说在监控旧的master吗？），至多在5s前回复过ping请求，通过发布/订阅通道（hello channel）报告说自己可以执行failover，并且不处于无法连接状态。

sentinel rule #12（原文中顺序是这样的）：如果master挂了（is down，没说是什么S、O状态），大家用rule 4所说的方式向每一个连接上了的sentinel发sentinel is-master-down-by-addr命令。这条命令的回复包括各个sentinel自己认为的subjective leader的runid。如果一个sentinel收到N个回复（包括它自己）认为它是个subjective leader，那么他就能认为自己是个objective leader，其中，N必须大于等于我们配置的值；N必须大于等于投票的sentinel总数的大多数（num_voters/2+1），这里只考虑同样认为master挂了的sentinel。（投票的大多数？万一配置的sentinel有10个，投票的只有3个，这三个都是因为发生错误才认为master挂了，怎么办？）

sentinel rule #13：满足下列条件后，某个sentinel将作为leader，开始failover（也即是说，这个sentinel确实要向redis server发送重新配置（reconfigure）的命令了）：master处于ODOWN状态；这个sentinel配置项中can-failover一项被设为yes；在这个sentinel看来至少有有个good slave；这个sentinel认为它是个objective leader；没有正在运行的failover进程。（There is no failover in progress already detected for this master. 不知道是否翻译失误）。

sentinel rule #14：同时满足下列条件后，某个sentinel会作为一个observer，检测到failover的开始（也就是说，它只会根据failover在log file和Pub/Sub接口中生成相应事件，但并不真的重新配置实例（这里是instances，难道一个sentinel监控多个redis master/slave？））：当前没有正在进行的failover；被监控的前master的一个slave实例被转变成了master。但是，如果一个slave实例转变成master并且同时runid改变了，failover不会被触发，因为这个slave之所以变成master，很可能是重启造成的，这并不能把它看成一次slave 选举。（问：这种情况是直接让这个重启的master上了吗？）

sentinel rule #15：将要start failover的sentinel并不马上start failover。它先进入一个时长为5s-15s之间一个随机时间的“wait-start”模式。在这段时间内sentinel rule#14依然生效：if a valid slave promotion is detected the failover as leader is aborted and the failover as observer is detected.（又不懂翻译了！the failover as observer is detected是神马意思！）

end of failover：

当sentinel觉得以下情况（同时？）满足时，它认为failover进程已经终止了：

被提升的slave不处于SDOWN状态。

某个slave被提升为新的master。

所有其他的slave都被重新配置到新的master上。

注意：处于SDOWN状态的slave将被忽略。

当以下情况满足时，sentinel认为failover整个过程已经终止：

被提升的slave不处于SDOWN状态。

某个slave被提升为master。

At least failover-timeout milliseconds elapsed since the last progress. （progress是指？）

可在每个sentinel的sentinel.conf中配置不同的failover-timeout值。

when a leader terminates a failover for timeout,（什么timeout？指filover-timeout吗？），它会尽力发送slaveof命令给所有还没被重新配置的slave，希望他们能接收到请求并且与master保持最终一致性。

sentinel rule #16：在leader或observer看来，满足以下情况的话，failover被看做成功完成：某个slave被提升成master（并且在sentinel看来，他能通过INFO的回复检测到这些），并且所有别的sentinel都被配置成与新master保持最终一致性（仍然通过INFO来探测）；已经存在一个正确的被提升了的slave，并且fileover-timeout时间到达后，没有任何其他的slave在进行reconfiguration的操作（additional我翻译成了其他）。这种情况下leader尽力向所有没被reconfigure的slave发送slave of命令。在以上两种情况中，被提升的slave必须是可连接的（不处于SDOWN状态），否则failover永远都不会被认为已完成。