总结写在前面：
- 使用cluster failover命令进行手动主从切换
- cluster failover命令的参数
- redis集群的切换步骤（理论）
redis集群的故障切换可以分成自动和手动两种。例如部署的3主3从的集群，如果一台master节点宕机，redis集群有能力自动选举新的主节点，完成故障迁移，保障系统的高可用性。
本文记录的故障切换是手动的操作，意义在于
- 当集群完全正常时，因为某些原因需要主从进行切换。例如我们需要下线某台服务器进行服务器升级。
- 当集群中多数master节点宕机，集群已不可用时的快速恢复。
操作
命令部分很简单，要注意的是这个命令必须在备节点上执行
cluster failover
或者
cluster failover force
或者
cluster failover takeover
第一种情况，集群正常时
这种情况是我们按计划进行服务器升级时，经常遇到的情况。
要升级的服务器上可能跑着很多个master节点，我们应该在变更前将该服务器上的master节点进行主备切换，这样下线服务器时可以做到业务应用无感知。
操作很简单,这种情况下只要在备节点上执行
cluster failover
具体redis做的切换步骤
- slave节点告知其master节点停止处理来自业务的请求
- master 节点将当前replication offset 回复给该slave节点
- salve节点在master节点的变更没有全部同步到自己时（追上replication offset），不会进行主备切换动作。
- salve节点追上replication offset，开始进行主备切换的工作：从集群中其他master处获取最新的epoch，然后广播自己的配置
- 原master节点收到配置更新:解除客户端的访问阻塞，回复重定向信息，以便客户端可以和新master通信。
第二种情况，集群已宕机
第二种情况就比较紧急了，可能遇到了意外情况导致多台或者全部master宕机，或者遇到网络分区隔离。测试redis集群已经是不可用状态。如果备节点都在，我们可以使用failover快速恢复redis集群服务。
此时在备节点上执行
cluster failover takeover
在上面第一种情况时，主备切换的第四步中需要从集群中其他master处获取最新的epoch。所以如果多数master已经宕机的情况下，是会获取失败的。
加上参数takeover，备节点会自己生成epoch。如果epoch不是最大的，则取当前有效epoch值中的最大值并自增作为新的配置epoch。
然后将原master节点管理的所有哈希槽分配给自己，接着就广播配置。
如此可以快速恢复集群能力。
有得必有失
TAKEOVER 违反Redis群集的last-failover-wins 原则，因为这种情况下epoch是备节点自己产生的，并没有同集群进行协商，所以可能存在冲突。
所以非紧急情况下不要使用takeover参数
没有用到的force
failover还有一个参数是force。
加上force的切换步骤是，不可master节点进行协商，直接开启第四步从集群中其他master处获取最新的epoch，然后广播自己的配置
所以，使用force的前提是多数master依然活着。
那么，这种情况下，如果master节点宕机，redis集群可以自动选出主节点切换。也不需要使用failover手动切换
所以，我没用过这个参数，没有什么场景适合使用。
网友评论