前言:
紧接上篇主从模式,为了解决主从的主节点故障时,不能切换的问题,引入了哨兵(sentinel)模式。
一.介绍
根据官网https://redis.io/topics/sentinel的介绍,哨兵模式是redis提供的一套高可用的解决方案,用来面对redis失败的时,不需要人为去干涉。
Sentinel的当前版本称为Sentinel 2。它使用更强大且更易于预测的算法(在本文档中进行了说明)重写了Sentinel的初始实现。
自Redis 2.8起已发布稳定版本的Redis Sentinel。
在不稳定分支中进行了新的开发,并且有时新功能一旦被认为是稳定的,便会立即移植回最新的稳定分支。
Redis 2.6附带的Redis Sentinel版本1已被弃用,不应使用。
根据官方文档介绍,哨兵(sentinel)模式在宏观层面有以下的作用。
- Monitoring. Sentinel constantly checks if your master and replica instances are working as expected.
- Notification. Sentinel can notify the system administrator, or other computer programs, via an API, that something is wrong with one of the monitored Redis instances.
- Automatic failover. If a master is not working as expected, Sentinel can start a failover process where a replica is promoted to master, the other additional replicas are reconfigured to use the new master, and the applications using the Redis server are informed about the new address to use when connecting.
- Configuration provider. Sentinel acts as a source of authority for clients service discovery: clients connect to Sentinels in order to ask for the address of the current Redis master responsible for a given service. If a failover occurs, Sentinels will report the new address.
1.监控(Monitoring) :哨兵(sentinel)会不断检查你的主节点(master)和从节点(slave)是否正常的运行
2.通知(Notification):当检查到某个redis实例出错时,哨兵(sentinel)可以通过API告知其他程序
3.自动故障迁移(Automatic failover):如果一个主节点(master)不能正常工作的时候,:哨兵(sentinel)可以开启 故障切换进程,里面的一个从节点(replica)会被提升做主节点(master),然后其他的从节点会被使用这个新的主节点(master)重新配置,当其他使用这个redis服务的程序连接redis服务时也会被告知这个新的地址
4.环境配置提供者(Configuration provider):哨兵作为客户端服务发现的授权源:客户端连接哨兵时询问当前redis主节点的地址,当发生故障迁移时,哨兵会报告新地址。
哨兵(sentinel)模式的工作原理
Redis Sentinel具有两个不同关闭概念,一个称为主观关闭状态(SDOWN),它是给定Sentinel实例本地的关闭状态。另一个称为客观停机 状态(ODOWN),当足够多的Sentinels(至少是配置为quorum
受监视主服务器的参数的数量)达到SDOWN条件并使用该SENTINEL is-master-down-by-addr
命令从其他Sentinels获得反馈时,就会达到该状态。
从Sentinel的角度来看,如果在配置中指定的秒数内未收到对PING请求的有效回复,则达到SDOWN条件is-master-down-after-milliseconds
。
可接受的对PING的答复是以下一种:
- PING回复了+ PONG。
- PING答复-LOADING error。
- PING答复-MASTERDOWN error。
任何其他答复(或根本没有答复)均被视为无效。但是请注意,在INFO输出中将自己作为副本发布的逻辑主节点(master)被视为已关闭。
一个如果一个节点在起设置的间隔时间范围内没有接受到有效的答复,则认为该节点SDOWN。如果一个节点在29s接收到有效的回复则认为该节点在工作(其间隔时间为30000ms即30s)
但是SDOWN是不足以出发故障迁移的,要触发此状态,需要达到ODOWN状态。
判定一个节点是否是ODOWN很简单,只需要有足够多的sentinel认为该节点在给点时间范围内没有工作,则认为该节点ODOWN。同时也需要注意到ODOWN状态只适用于master。
二.配置
根据官网以下是最小配置
# mymaster是给master自己取名字 监控本机的ip,端口为6379,2为仲裁系数(quorum),当有两个以上sentinel认为该master不工作时,开启故障迁移
sentinel monitor mymaster 127.0.0.1 6379 2
#down-after-milliseconds是指在指定时间内没有范围ping的结果或者带ping的错误信息的所设置的毫秒数(判断为主观下线SDOWN)
sentinel down-after-milliseconds mymaster 60000
#指过一段时间后,再对该节点进行故障迁移
sentinel failover-timeout mymaster 180000
#指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长,但越大就意味着越多的从服务器因为复制而不可用。可以通过将这个值设为 1 来保证每次只有一个从服务器处于不能处理命令请求的状态。
sentinel parallel-syncs mymaster 1
我本地的配置
#当前Sentinel服务运行的端口
protected-mode no
bind 127.0.0.1
port 10001
sentinel monitor mymaster 192.168.238.1 6379 1
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 10000
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码,没有的话不用设置
sentinel auth-pass mymaster 123456
需要注意一下,redis推荐最少三台的sentinel来保证其健壮性。
触发failover的条件有二:
1.认为master为ODOWN>=上面的仲裁系数(quorum)
2.大多数的sentinel之间能够通信。当只有两台sentinel的时候,大多数为2;3台sentinel的时候,大多数为2,5台sentinel的时候大多数为3.
三.配置实战
3.1.在redis文件下新建sentinel.conf文件
#当前Sentinel服务运行的端口
protected-mode no
bind 127.0.0.1 #最好再加本地ip
port 10001
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 10000
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码,没有的话不用设置
sentinel auth-pass mymaster 123456
因为我是在同一台电脑下启动,不同的sentinel用不同的port。(s1->10001,s2->10002,s3->10003)
3.2.先启动redis的master和slave(windows下可参考我上边文章,linux的自己查一下)。
3.3在redis目录下cmd进入,执行redis-server.exe sentinel.conf --sentinel命令
这样我们就在本机启动两个redis,三个sentinel了
3.4关闭redis 的master
通过vote,redis主节点从6380转到6379