Redis 5.0.4-搭建3主3从3哨兵,实现高可用性与故障转移
上回书说道,使用 Redis 5.0.4 工具搭建集群。默认是3主3从。那么想增加哨兵怎么做呢?
搭建哨兵的前提下,先搭建主从集群
链接:Redis 5.0.4搭建集群
高可用性与故障转移
服务器的高可用性是指服务器能提供7*24小时不间断的服务,Redis可以通过Sentinel系统管理多个Redis服务器,当master服务器发生故障时,Sentineal系统会根据一定的规则将某台slave服务器升级为master服务器,继续提供服务,实现故障转移,保证Redis服务不间断。
一、为什么用到哨兵
哨兵(Sentinel)主要是为了解决在主从复制架构中出现宕机的情况,主要分为两种情况:
- 主从环境下,从服务器宕机
这个相对而言比较简单,在Redis中从库重新启动后会自动加入到主从架构中,自动完成同步数据。在Redis2.8版本后,主从断线后恢复的情况下实现增量复制。 - 主从环境下,主服务器宕机
这个相对而言就会复杂一些,需要以下2步才能完成
- 在从数据库中执行SLAVEOF NO ONE命令,断开主从关系并且提升为主库继续服务
- 将主库重新启动后,执行SLAVEOF命令,将其设置为其他库的从库,这时数据就能更新回来
由于这个手动完成恢复的过程其实是比较麻烦的并且容易出错,所以Redis提供的哨兵(sentinel)的功能来解决
二、什么是哨兵
Redis-Sentinel是用于管理Redis集群,该系统执行以下三个任务:
- .监控(Monitoring):Sentinel会不断地检查你的主服务器和从服务器是否运作正常
- 提醒(Notification):当被监控的某个Redis服务器出现问题时,Sentinel可以通过API向管理员或者其他应用程序发送通知
- 自动故障迁移(Automatic failover):当一个主服务器不能正常工作时,Sentinel 会开始一次自动故障迁移操作,它会将失效主服务器的其中一个从服务器升级为新的主服务器,并让失效主服务器的其他从服务器改为复制新的主服务器;当客户端试图连接失效的主服务器时,集群也会向客户端返回新主服务器的地址,使得集群可以使用新主服务器代替失效服务器
多个哨兵,不仅同时监控主从数据库,而且哨兵之间互为监控
三、哨兵搭建
#进入安装目录
$ cd /usr/local/redis/redis-5.0.4
#创建哨兵配置文件目录
$ mkdir sentinel
# 复制3份配置文件,分别为20014.conf、20015.conf、20016.conf
$ cp sentinel.conf ./sentinel/20014.conf
四、配置文件
$ cd sentinel
$ vim 30014.conf
修改配置文件如下:
# 添加守护进程模式
daemonize yes
# 添加指明日志文件名
logfile "/usr/local/redis/redis-5.0.4/sentinel/20014.log"
# 修改工作目录
dir "/usr/local/redis/redis-5.0.4/sentinel"
# 修改启动端口
port 20014
# 关闭保护模式
protected-mode no
# 修改sentinel monitor,此处需要配置的端口为主节点端口
sentinel monitor redis-test-master 127.0.0.1 30011 2
#如果主从配置了密码需要增加此参数
sentinel auth-pass redis-test-master 123456
# 将配置文件中mymaster全部替换
依次修改20015,20016配置
说明:
redis-test-master:监控主数据的名称,自定义即可,可以使用大小写字母和“.-_”符号
127.0.0.1:监控的主数据库的IP
30011:监控的主数据库的端口
2:最低通过票数
敲黑板,画重点
- daemonize 设置为守护进程,否则在启动的时候则会卡在命令界面
- sentinel monitor 必须为主节点ip和端口
- sentinel monitor 后面的 redis-test-master 如果不是默认的 mymaster 则需要文件中用到 mymaster 的地方全部修改,否则启动时将会报错找不到 mymaster
启动命令
$ cd src
$ ./redis-sentinel ../sentinel/20014.conf 或者 ./redis-server ../sentinel/20014.conf --sentinel
查看命令
$ ../src/redis-cli -p 20015
$ info sentinel
五、Sentinel 原理
首先解释2个名词:SDOWN 和 ODOWN
- SDOWN:subjectively down,直接翻译的为“主观”失效,即当前sentinel实例认为某个redis服务为“不可用”状态.
- ODOWN:objectively down,直接翻译为“客观”失效,即多个sentinel实例都认为master处于”SDOWN”状态,那么此时master将处于ODOWN,ODOWN可以简单理解为master已经被集群确定为“不可用”,将会开启failover
SDOWN与ODOWN转换过程:
- 每个sentinel实例在启动后,都会和已知的slaves/master以及其他sentinels建立TCP连接,并周期性发送PING(默认为1秒),在交互中,如果redis-server无法在“down-after-milliseconds”时间内响应或者响应错误信息,都会被认为此redis-server处于SDOWN状态。
- SDOWN的server为master,那么此时sentinel实例将会向其他sentinel间歇性(一秒)发送“is-master-down-by-addr ip port”指令并获取响应信息,如果足够多的sentinel实例检测到master处于SDOWN,那么此时当前sentinel实例标记master为ODOWN…其他sentinel实例做同样的交互操作.配置项“sentinel monitor mastername masterip masterport quorum”,如果检测到master处于SDOWN状态的slave个数达到quorum,那么此时此sentinel实例将会认为master处于ODOWN。
每个sentinel实例将会间歇性(10秒)向master和slaves发送“INFO”指令,如果master失效且没有新master选出时,每1秒发送一次“INFO”,“INFO”的主要目的就是获取并确认当前集群环境中slaves和master的存活情况。
经过上述过程后,所有的sentinel对master失效达成一致后,开始failover。
Sentinel与slaves“自动发现”机制:
在sentinel的配置文件中,都指定了port,此port就是sentinel实例侦听其他sentinel实例建立链接的端口。在集群稳定后,最终会每个sentinel实例之间都会建立一个tcp链接,此链接中发送“PING”以及类似于“is-master-down-by-addr”指令集,可用用来检测其他sentinel实例的有效性以及“ODOWN”和“failover”过程中信息的交互。在sentinel之间建立连接之前,sentinel将会尽力和配置文件中指定的master建立连接。sentinel与master的连接中的通信主要是基于pub/sub来发布和接收信息,发布的信息内容包括当前sentinel实例的侦听端口。
上一篇: redis(一主两从三哨兵模式搭建)记录