Redis哨兵(Sentinel)

主要配置

bind  0.0.0.0        #bind 默认情况下，Sentinel不能从不同的接口访问localhost，（默认只监听127.0.0.1），可以使用'bind'指令绑定到网络列表接口
protected-mode no    #禁用保护模式
daemonize yes        #是否以守护进程的方式启动
port  26379          #默认比redis端口的大20000
dir  "/data/redis/sentinel_26379"  #工作目录  自定义目录先创建
logfile "/data/redis/logs/sentinel_26379.log"  #日志  自定义文件先创建
sentinel monitor mymaster 10.16.134.65 6379 2   #指定sentinel监控某个master。并且如果master进入O_DOWN 状态，至少需要<quorum> 个 sentinel 同意。注意，无论ODOWN quorum 数是多少，一个sentinel需要被大多数已知的sentinel选举才能开始故障迁移，所以不能在少数sentinel选举的情况下执行故障切换。slave 是自动发现的，因此不需要在配置文件中明确指定。sentinel发现slave后会自动重写配置文件。需要注意的是，当一个slave提升为master时，sentinel配置也会被重写
sentinel down-after-milliseconds mymaster 30000  #多少毫秒内，master 不可达就会被sentinel 认为是进入了 S_DOWN 状态。如果服务器在给定的毫秒数之内，没有返回Sentinel发送的PING命令的回复，或者返回一个错误，那么Sentinel将这个服务器标记为主观下线(subjectively down，简称SDOWN)。默认是30s
sentinel parallel-syncs mymaster 1  #这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
sentinel failover-timeout mymaster 180000   #如果在多少毫秒内没有把宕掉的那台Master恢复，那Sentinel认为这是一次真正的宕机。在下一次选取时排除该宕掉的Master作为可用的节点，然后等待一定的设定值的毫秒数后再来探测该节点是否恢复，如果恢复就把它作为一台Slave加入Sentinel监测节点群，并在下一次切换时为他分配一个”选取号”。默认是3分钟

 cat sentinel.conf |grep -v "#" | grep -v "^$" > sentinel_26379.conf

启动sentinel

[root@localhost bin]# /usr/local/redis/bin/redis-sentinel /usr/local/redis/sentinel_26379.conf 
[root@localhost bin]# ps -ef |grep redis
root      2474     1  0 10:18 ?        00:00:34 /usr/local/redis/bin/redis-server 0.0.0.0:6379               
root     18255  1820  0 14:25 pts/0    00:00:00 ./redis-cli
root     26125     1  6 15:10 ?        00:00:00 /usr/local/redis/bin/redis-sentinel 0.0.0.0:26379 [sentinel]            
root     26226 19663  0 15:10 pts/1    00:00:00 grep redis
[root@localhost redis]# cat sentinel_26379.conf   #配置文件发生改变
port 26379
daemonize yes
bind 0.0.0.0
protected-mode no
pidfile "/var/run/redis-sentinel.pid"
logfile "/data/redis/logs/sentinel_26379.log"
dir "/data/redis/sentinel_26379"
sentinel myid 2e39c78f08bf6ff52d1fba99a5e86577f840c40a
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 10.16.134.65 6379 2
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
# Generated by CONFIG REWRITE
maxmemory 3gb
sentinel known-replica mymaster 10.16.134.75 6379
sentinel known-replica mymaster 10.16.134.85 6379
sentinel current-epoch 0

故障转移测试

正常运行一主两从

master宕机  *从机配置  protected-mode no 开启,不然salve无法切换*

原来的master恢复变成slave

三个定时任务

1)每10秒每个sentinel对master和slave执行info

• 发现salve节点

• 确认主从关系

2)每2秒每个sentinel通过master节点的channel交换信息(pub/sub)

• 通过_sentinel_:hello频道交换

• 交换对节点的"看法"和自身信息

3)每1秒每个sentinel对其他sentinel和redis执行ping

• 心跳检测,失败判定依据

主观下线和客官下线

sentinel monitor mymaster 10.16.134.65 6379 2   #指定sentinel监控某个master。并且如果master进入O_DOWN 状态，至少需要<quorum> 个 sentinel 同意。注意，无论ODOWN quorum 数是多少，一个sentinel需要被大多数已知的sentinel选举才能开始故障迁移，所以不能在少数sentinel选举的情况下执行故障切换。slave 是自动发现的，因此不需要在配置文件中明确指定。sentinel发现slave后会自动重写配置文件。需要注意的是，当一个slave提升为master时，sentinel配置也会被重写
sentinel down-after-milliseconds mymaster 30000  #多少毫秒内，master 不可达就会被sentinel 认为是进入了 S_DOWN 状态。如果服务器在给定的毫秒数之内，没有返回Sentinel发送的PING命令的回复，或者返回一个错误，那么Sentinel将这个服务器标记为主观下线(subjectively down，简称SDOWN)。默认是30s

• 主观下线 : 每个sentinel节点对redis节点失败的"偏见"

• 客观下线 : 所有sentinel节点对redis节点失败"达成共识" (超过quorum个统一 *建议三个节点设置为2,超过3个节点设置为 节点数/2+1*)

领导者选举

原因 : 只有一个sentinel节点完成故障转移

选举 : 通过sentinel is-master-down-by-addr命令都希望成为领导者

1. 每个做主观下线的sentinel节点向其他sentinel节点发送命令,要求将它设置为领导者

2. 收到命令的sentinel节点如果没有同意其他sentinel节点发送的命令,那么将同意该请求,否则拒绝

3. 如果该sentinel节点发现自己的票数已经超过sentinel集合半数且超过quorum,那么它将成为领导者

4. 如果此过程中有多个sentinel节点成为领导者,那么将等待一段时间重新进行选举

故障转移

1. 在salve节点中选出一个"合适的"节点作为新的master节点

2. 对上面的slave节点执行slaveof no one命令让其成为master节点

3. 想剩余的slave节点发送命令,让它们成为新master节点的slave节点,复制规则和parallel-syncs参数相关

4. 更新对原来master节点配置为slave,并保持对其"关注",当其恢复后命令它去复制新的master节点

选择"合适的"slave节点

1. 选择slave-priority(slave节点优先级)最高的slave节点,如果存在则返回,不存在则继续 *默认不配置,除非slave有一台配置好的,希望master宕机后由这台成为master*

2. 选择复制偏移量最大的slave节点(复制的相对完整),如果存在则返回,不存在则继续     

3. 选择runId最小的slave节点(启动最早的)