Redis哨兵详解,哨兵搭建流程,哨兵的运行流程和选举原理(主观下线,客观下线,如何选举出哨兵leader)。
Redis哨兵(sentinel)
哨兵是什么?
吹哨人巡查监控后台master主机是否故障,如果故障了根据投票数自动将某一个从库转换为新主库,继续对外服务。
俗称,无人值守运维。
干什么?
- 主从监控:监控主从redis库运行是否正常
- 消息通知:哨兵可以将故障转移的结果发送给客户端
- 故障转移:将其中一个Slave作为新的Master
- 配置中心:客户端通过连接哨兵来获得当前Redis服务的主节点地址
案例
架构
3个哨兵:自动监控和维护集群,不存放数据,只是吹哨人。
1主2从:用于读取和存放数据
步骤
-
将redis安装路径下的 sentinel.conf 拷贝到 myredis目录下
cp sentinel.conf /myredis/sentinel26379.conf
-
修改配置文件
vim sentinel26379.conf bind 0.0.0.0 # protected-mode yes 修改为 protected-mode no protected-mode no # daemonize no 修改为 daemonize yes daemonize yes # port port 26379 # pid文件名字,pidfile pidfile /var/run/redis_26379.pid # log文件名字,logfile(修改 logfile "" 为 logfile "/myredis/26379.log") logfile "/myredis/26379.log" # 指定当前的工作目录(修改 dir /temp 为 dir /myredis) dir /myredis
设置要监控的master服务器
quorum:确认客观下线的最少哨兵数量。同意故障迁移的法定票数。
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
设置连接master服务的密码
# sentinel auth-pass <master-name> <password>
我们知道,网络是不可靠的,有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了,在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了,quorum这个参数是进行客观下线的一个依据,意思是至少有quorum个sentinel认为这个master有故障,才会对这个master进行下线以及故障转移。因为有的时候,某个sentinel节点可能因为自身网络原因,导致无法连接master,而此时master并没有出现故障,所以,这就需要多个sentinel都一致认为该master有问题,才可以进行下一步操作,这就保证了公平性和高可用。
安装三台linux
ip和port分别为
# sentinel00 192.168.157.112 26379 # sentinel01 192.168.157.113 26380 # sentinel02 192.168.157.118 26381
配置三台哨兵
sentinelxxxx.conf 文件
sentinel00
sentinel26379.conf
bind 0.0.0.0 daemonize yes protected-mode no port 26379 logfile "/myredis/sentinel26379.log" pidfile /var/run/redis-sentinel26379.pid dir /myredis sentinel monitor mymaster 192.168.157.115 6379 2 sentinel auth-pass mymaster 1234
sentinel01
sentinel26380.conf
bind 0.0.0.0 daemonize yes protected-mode no port 26380 logfile "/myredis/sentinel26380.log" pidfile /var/run/redis-sentinel26380.pid dir /myredis sentinel monitor mymaster 192.168.157.115 6379 2 sentinel auth-pass mymaster 1234
sentinel02
sentinel26381.conf
bind 0.0.0.0 daemonize yes protected-mode no port 26381 logfile "/myredis/sentinel26381.log" pidfile /var/run/redis-sentinel26381.pid dir /myredis sentinel monitor mymaster 192.168.157.115 6379 2 sentinel auth-pass mymaster 1234
测试
-
基于之前的 redis复制,启动1主2从测试是否主从复制是否正常,输入 info replication 查看是否正常
-
启动三台哨兵,完成监控
redis-sentinel /myredis/sentinel26379.conf --sentinel redis-sentinel /myredis/sentinel26380.conf --sentinel redis-sentinel /myredis/sentinel26381.conf --sentinel
-
测试主从复制,一切良好
-
查看日志
-
查看配置文件 sentinel.conf
> 后面为自动新增内容
-
模拟master宕机
-
master主机
# 模拟宕机 shudown
问题
- 两台从机数据是否正常?(yes)
- 会不会从剩下的两台机器中选出新的master?(yes)
- 之前的master重启之后会不会重新上位,重新成为master?(no)
-
salve获取数据
-
查看新的master
-
重写启动原master
master不会重新上位。
对比配置文件
文件的内容,在运行期间会被sentinel动态修改。master—slave主从关系切换后,配置文件内容会自动发生改变。
-
sentinel6379.conf 文件
-
旧 master
-
新master
哨兵运行流程和选举原理
当一个主从配置中的master失效后,sentinel可以选举出一个新的master用于自动替换原master的工作,主从配置中的其他redis服务自动指向新的master同步数据,一般建议sentinel采取奇数台,防止某一台sentinel无法连接到master导致误切换。
SDown主观下线(Subjectively Down)
SDOWN(主观不可用)是单个哨兵自己主观检测到的关于master的状态,从sentinel的角度来看,如果发送了PING心跳后,在一定时间内没有收到合法的回复,就到达了SDOQN的条件。
sentinel配置文件中的 down-after-milliseconds 设置了主观下线的时间长度(默认30秒)。
# sentinel down-after-milliseconds <masterName> <timeout> sentinel down-after-milliseconds mymaster 30000
ODown客观下线(Objectively Down)
ODOWN需要一定数量的sentinel,多个哨兵达成一致意见才能确认一个master客观上已经宕机了。
# sentinel monitor <master-name> <ip> <redis-port> <quorum> sentinel monitor mymaster 127.0.0.1 6379 2
选举出领导者哨兵
当主节点被判断客观下线后,各个哨兵节点会进行协商,先选举出一个领导者哨兵节点,并由该领导者哨兵节点进行failover(故障迁移)
领导者哨兵如何选出来的?
Raft算法
监视该主节点的所有哨兵都有可能被选为领导者,选举使用的算法是Raft算法;Raft算法的基本思路是先到先得,即在一轮选举中,哨兵A向B发送成为领导者的申请,如果B没有同意过其他哨兵,则会同意A成为领导者。
选新的master(im)
整个过程由sentinel自己独立完成,无需人工干涉。
新主登基
某一个slave被选中成为master
选出新的master的规则,剩余slave节点健康的前提下
- redis.conf文件中,优先级slave-priority或者replica-priority最高节点(数字越小优先级越高)
- 复制偏移量offset最大的从节点。
- 最小Run ID的从节点。
群臣俯首
-
执行 slaveof no one 命令让选出来的从节点成为新的主节点,并通过 slaveof 命令让其他节点成为其从节点。
-
sentinel leader 会对选举出来的新 master 执行 slaveof no one,将其提升为master节点
-
sentinel leader 向其他slave发送命令,让剩余的slave成为新的master节点的slave。
旧主拜服
- 将之前的已经下线的旧master设置为新选出的新master的从节点,当旧master重新上线后,它会成为新master的从节点
- sentinel leader 会让原来的master降级为slave并恢复正常工作。
哨兵使用建议
- 哨兵节点数量应该为多个,哨兵本身应该为集群,保证高可用
- 哨兵节点数量应该是奇数
- 各个哨兵节点的配置应该一致
- 如果哨兵节点部署在docker等容器里面,尤其要注意端口的正确映射
- 哨兵集群 + 主从复制,并不能保证数据零丢失