Redis集群部署——sentinel模式

容器化运行sentinel实例

1、获取sentinel.conf配置文件

从官网下载对应的tar包，解压找到对应的sentinel.conf配置文件，修改其中的配置文件

注意：

# 设置监听节点，最后的数字2是quorum，表示客观下线时需要多少哨兵服务同意
sentinel monitor master <redis-master-ip> 6379 2
# 设置验证密码 避免不必要的错误信息
sentinel auth-pass master 123456
# 设置master服务失联10s后主观下线
sentinel down-after-milliseconds master 10000
# 设置同步数据超时时间为60s
sentinel failover-timeout master 60000

2、启动哨兵实例

docker run --name sentinel1 \
  -v /opt/sentinel.conf:/etc/sentinel.conf
  redis redis-sentinel /etc/sentinel.conf

常见的哨兵日志

1. +sdown master mymaster 192.168.50.121 6379

当前哨兵认为master已经主观宕机，也就是sdown。

2.  +odown master mymaster 192.168.50.121 6379 #quorum 2/2

由于哨兵集群内有超过两个哨兵都认为master sdown了，因此转化成客观宕机，也就是odown。

3.  +new-epoch 1

递增集群状态版本号，这个版本号将被接下来选举出的新的master采用。

从这个可以看出，集群版本号是哨兵创建和维护的。

4. +vote-for-leader 2d271223c7df8d1d54967ee893fbebfbf6c60ab1 1

在哨兵集群中投票选举出一个哨兵，作为本次执行故障转移操作的leader。

5.  +try-failover master mymaster 192.168.50.121 6379

开始对IP为192.168.50.121，端口为6379，名为"mymaster"的Redis集群进行故障转移

6.  +vote-for-leader 2d271223c7df8d1d54967ee893fbebfbf6c60ab1 1

当前哨兵投票给自己满意的slave

7. 337d50c8ef65a708ad27be2ce1ab9d3552046b64 voted for 2d271223c7df8d1d54967ee893fbebfbf6c60ab1 1

另一个哨兵投票给自己满意的slave

8.  ce1868c3f2dcc412d2348ffa6ccb5e6222ad1a47 voted for 2d271223c7df8d1d54967ee893fbebfbf6c60ab1 1

另一个哨兵投票给自己满意的slave

9.  +elected-leader master mymaster 192.168.50.121 6379

在哨兵集群中再次确认进行即将执行故障转移的leader是哪一个哨兵。

10. +failover-state-select-slave master mymaster 192.168.50.121 6379

leader开始在集群中寻找合适的slave。(从这里可以看出，找出新的slave不单单是通过投票，可能还和其它的因素有关。)

11.  +selected-slave slave 192.168.50.122:6379 192.168.50.122 6379 @ mymaster 192.168.50.121 6379

出现"+selected-slave"意味着已经找到了合适的slave作为新的master，它是位于S2服务器上的192.168.50.122 6379 Redis服务。

12.  +failover-state-send-slaveof-noone slave 192.168.50.122:6379 192.168.50.122 6379 @ mymaster 192.168.50.121 6379

Leader向目标slave发送"slaveof-noone"指令，令其不要再做其它任何节点的slave了，从现在开始，它就是老大，完成从slave到master的转换。

13. +failover-state-wait-promotion slave 192.168.50.122:6379 192.168.50.122 6379 @ mymaster 192.168.50.121 6379

等待其它的sentinel确认slave

14. +promoted-slave slave 192.168.50.122:6379 192.168.50.122 6379 @ mymaster 192.168.50.121 6379

”+promoted-slave“ 意味着其它的sentinel全部确认成功。

15.  +failover-state-reconf-slaves master mymaster 192.168.50.121 6379

开始对集群中的所有slave做reconf操作(更新配置信息)。

16. +slave-reconf-sent 

向指定的slave发送"slaveof"指令，令其跟随新的master。

17. +slave-reconf-inprog 

目标slave正在执行slaveof操作，如果在此期间，又接收到了新的"slave-reconf-sent"命令，则在会在当前操作执行完毕后，再次执行slaveof。

18. +slave-reconf-done

目标slave配置信息更新完毕，leader可以对下一个slave开始reconfig操作了。

19.  +failover-end master mymaster 192.168.50.121 6379

本次故障转移完毕。

 20. +switch-master mymaster 192.168.50.121 6379 192.168.50.122 6379

故障转移完毕后，各个sentinel开始监控新的master。

这句话执行完毕后，我们可以去哨兵的配置文件中看到，sentinel monitor mymaster后面的ip已经发生了变化。