Redis哨兵模式及配置

前言

在上一篇redis的主从复制中已经实现了redis的主从架构，但是如果redis的主从架构中出现宕机怎么办？如果从redis宕机相对简单一些，那么如果住redis的宕机就会比较麻烦，需要我们手动进行处理，这样很可能会造成数据的丢失，这时候我们就需要用到Redis提供的哨兵（sentinel）功能，哨兵会在master发送故障的时候，能自动将slave切换成master，下面就对哨兵做一个介绍。

Sentinel（哨兵）

介绍

Redis SentinelSentinel(哨兵)是用于监控redis集群中Master状态的工具，其已经被集成在redis2.4+的版本中

作用

    1)：Master状态检测
    2)：如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave
    3)：Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

哨兵模式的原理

Redis提供了sentinel（哨兵）机制，通过sentinel模式启动redis后，自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决
每个sentinel会向其它sentinal、master、slave定时发送消息，以确认对方是否“活”着，如果发现对方在指定时间（可配置）内未回应，则暂时认为对方已挂（所谓的“主观认为宕机” Subjective Down，简称SDOWN）。
若”哨兵群”中的多数sentinel，都报告某一master没响应，系统才认为该master”彻底死亡”(即：客观上的真正down机，Objective Down，简称ODOWN)，通过一定的vote算法，从剩下的slave节点中，选一台提升为master，然后自动修改相关配置。
这里写图片描述

哨兵模式的配置

在redis的主从配置中，我们已经设置好了6380作为master6381,6382作为salve，现在我们在redis-jiqun目录下建一个sentinel.conf，或者我们从redis的解压目录将sentinel.conf文件复制到redis-jiqun目录中：
sentinel.conf的内容如下

port 26379  
dir /tmp  
sentinel monitor mymaster 192.168.251.129 6380 1  
sentinel down-after-milliseconds mymaster 30000  
sentinel parallel-syncs mymaster 1  
sentinel failover-timeout mymaster 180000  
logfile "/var/log/sentinel_log.log"

注释：
1. port :当前Sentinel服务运行的端口
2. dir : Sentinel服务运行时使用的临时文件夹
3 sentinel monitor mymaster 192.168.251.129 6380 1:Sentinel去监视一个名为master的主redis实例，这个主实例的IP地址为本机地址192.168.1.103，端口号为6379，而将这个主实例判断为失效至少需要1个 Sentinel进程的同意，只要同意Sentinel的数量不达标，自动failover就不会执行
4. sentinel down-after-milliseconds mymaster 300000:指定了Sentinel认为Redis实例已经失效所需的毫秒数。当实例超过该时间没有返回PING，或者直接返回错误，那么Sentinel将这个实例标记为主观下线。只有一个 Sentinel进程将实例标记为主观下线并不一定会引起实例的自动故障迁移：只有在足够数量的Sentinel都将一个实例标记为主观下线之后，实例才会被标记为客观下线，这时自动故障迁移才会执行
5. sentinel parallel-syncs mymaster 1：指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
6. sentinel failover-timeout mymaster 180000：如果在该时间（ms）内未能完成failover操作，则认为该failover失败

启动哨兵

方式一：redis-sentinel /path/to/sentinel.conf & (推荐，这种方式启动和redis实例没有任何关系，后面加&可以在后台启动,关闭ssh窗口依然会在后台执行)
在redis01的bin目录下执行：

./redis-sentinel /usr/local/redis-jiqun/sentinel.conf &

方式二：redis-server /path/to/sentinel.conf –sentinel，前台启动，ctril+c进行关闭

./redis-sentinel /usr/local/redis-jiqun/sentinel.conf --sentinel

测试哨兵

我们后台启动哨兵以后，可以在/var/log/sentinel_log.log中查看日志
这里写图片描述
现在我们停止6380master节点

#现在我们停止6380master节点
ps –ef |grep redis
kill -9 端口号
#查看log日志
cat /var/log/sentinel_log.log

这里写图片描述
下面就是模拟主节点宕机，哨兵进行工作的整个过程。

3349:X 07 Dec 13:52:17.982 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
3349:X 07 Dec 13:52:17.996 # Sentinel ID is 23e1e3e4fc3f181d30475fac45f3d10a481017f3
3349:X 07 Dec 13:52:17.996 # +monitor master mymaster 192.168.251.129 6380 quorum 1
3349:X 07 Dec 13:52:17.997 * +slave slave 192.168.251.129:6381 192.168.251.129 6381 @ mymaster 192.168.251.129 6380
3349:X 07 Dec 13:52:18.009 * +slave slave 192.168.251.129:6382 192.168.251.129 6382 @ mymaster 192.168.251.129 6380
3349:X 07 Dec 14:02:45.191 # +sdown master mymaster 192.168.251.129 6380   #说明master服务已经宕机
3349:X 07 Dec 14:02:45.191 # +odown master mymaster 192.168.251.129 6380 #quorum 1/1
3349:X 07 Dec 14:02:45.191 # +new-epoch 1
3349:X 07 Dec 14:02:45.192 # +try-failover master mymaster 192.168.251.129 6380  #开始恢复
3349:X 07 Dec 14:02:45.240 # +vote-for-leader 23e1e3e4fc3f181d30475fac45f3d10a481017f3 1  #投票选举哨兵leader，现在就一个哨兵所以leader就自己
3349:X 07 Dec 14:02:45.240 # +elected-leader master mymaster 192.168.251.129 6380  #选中leader
3349:X 07 Dec 14:02:45.241 # +failover-state-select-slave master mymaster 192.168.251.129 6380   #选中其中的一个slave当做master
3349:X 07 Dec 14:02:45.341 # +selected-slave slave 192.168.251.129:6382 192.168.251.129 6382 @ mymaster 192.168.251.129 6380  #这里选中的是6382slave
3349:X 07 Dec 14:02:45.342 * +failover-state-send-slaveof-noone slave 192.168.251.129:6382 192.168.251.129 6382 @ mymaster 192.168.251.129 6380  #发送slaveof no one命令
3349:X 07 Dec 14:02:45.419 * +failover-state-wait-promotion slave 192.168.251.129:6382 192.168.251.129 6382 @ mymaster 192.168.251.129 6380   #等待升级master
3349:X 07 Dec 14:02:45.500 # +promoted-slave slave 192.168.251.129:6382 192.168.251.129 6382 @ mymaster 192.168.251.129 6380  #升级6382为master
3349:X 07 Dec 14:02:45.500 # +failover-state-reconf-slaves master mymaster 192.168.251.129 6380 
3349:X 07 Dec 14:02:45.596 * +slave-reconf-sent slave 192.168.251.129:6381 192.168.251.129 6381 @ mymaster 192.168.251.129 6380
3349:X 07 Dec 14:02:46.244 * +slave-reconf-inprog slave 192.168.251.129:6381 192.168.251.129 6381 @ mymaster 192.168.251.129 6380
3349:X 07 Dec 14:02:46.244 * +slave-reconf-done slave 192.168.251.129:6381 192.168.251.129 6381 @ mymaster 192.168.251.129 6380
3349:X 07 Dec 14:02:46.334 # +failover-end master mymaster 192.168.251.129 6380 #故障恢复完成
3349:X 07 Dec 14:02:46.334 # +switch-master mymaster 192.168.251.129 6380 192.168.251.129 6382   #主数据库从6380转变为6382
3349:X 07 Dec 14:02:46.334 * +slave slave 192.168.251.129:6381 192.168.251.129 6381 @ mymaster 192.168.251.129 6382  #添加6381为6382的从库
3349:X 07 Dec 14:02:46.334 * +slave slave 192.168.251.129:6380 192.168.251.129 6380 @ mymaster 192.168.251.129 6382  #添加6380为6382的从库
3349:X 07 Dec 14:03:16.374 # +sdown slave 192.168.251.129:6380 192.168.251.129 6380 @ mymaster 192.168.251.129 6382  #这里检测6379还是宕机状态
3349:X 07 Dec 14:14:23.989 # -sdown slave 192.168.251.129:6380 192.168.251.129 6380 @ mymaster 192.168.251.129 6382  #一直在检测6380的状态
3349:X 07 Dec 14:14:33.895 * +convert-to-slave slave 192.168.251.129:6380 192.168.251.129 6380 @ mymaster 192.168.251.129 6382  #我们启动6380，他变成了6380的slave

参考资料

http://blog.csdn.net/yingxiake/article/details/51671335
https://baike.baidu.com/item/Sentinel/19266391
http://blog.csdn.net/qq_34021712/article/details/72026313