1、哨兵模式
哨兵模式是redis高可用的实现方式之一。使用一个或者多个哨兵(Sentinel)实例组成的系统,对redis节点进行监控,在主节点出现故障的情况下,能将从节点中的一个升级为主节点,进行故障转义,保证系统的可用性。
1、哨兵们是怎么感知整个系统中的所有节点(主节点/从节点/哨兵节点)的?
首先主节点的信息是配置在哨兵(Sentinel)的配置文件中
哨兵节点会和配置的主节点建立起两条连接命令连接和订阅连接
哨兵会通过命令连接每10s发送一次INFO命令,通过INFO命令,主节点会返回自己的run_id和自己的从节点信息
哨兵会对这些从节点也建立两条连接命令连接和订阅连接
哨兵通过命令连接向从节点发送INFO命令,获取到他的一些信息(run_id、 role、从服务器的复制偏移量 offset)
因为哨兵对与集群中的其他节点(主从节点)当前都有两条连接,命令连接和订阅连接
a. 通过命令连接向服务器的_sentinel:hello频道发送一条消息,内容包括自己的ip端口、run_id、配置纪元(后续投票的时候会用到)等b. 通过订阅连接对服务器的_sentinel:hello频道做了监听,所以所有的向该频道发送的哨兵的消息都能被接受到c. 解析监听到的消息,进行分析提取,就可以知道还有那些别的哨兵服务节点也在监听这些主从节点了,更新结构体将这些哨兵节点记录下来d. 向观察到的其他的哨兵节点建立命令连接----没有订阅连接
2、哨兵模式下的故障迁移
主观下线
哨兵(Sentinel)节点会每秒一次的频率向建立了命令连接的实例发送PING命令,如果在down-after-milliseconds毫秒内没有做出有效响应包括(PONG/LOADING/MASTERDOWN)以外的响应,哨兵就会将该实例在本结构体中的状态标记为SRI_S_DOWN主观下线
客观下线
当一个哨兵节点发现主节点处于主观下线状态是,会向其他的哨兵节点发出询问,该节点是不是已经主观下线了。如果超过配置参数quorum个节点认为是主观下线时,该哨兵节点就会将自己维护的结构体中该主节点标记为SRI_O_DOWN客观下线
询问命令SENTINEL is-master-down-by-addr <current_epoch> <run_id>
参数意义:
故障迁移:在从节点中挑选出新的主节点,将旧的主节点变成新的主节点的从节点
a. 通讯正常b. 优先级排序c. 优先级相同是选择offset最大的将该节点设置成新的主节点 SLAVEOF no one,并确保在后续的INGO命令时,该节点返回状态为master,将其他的从节点设置成从新的主节点复制, SLAVEOF命令
3、优缺点
优点:
高可用,在主节点故障时能实现故障的转移
缺点:
好像没办法做到水平拓展,如果内容很大的情况下
2、使用(redis-sentinel)配置高可用
前提:此实验是基于上一篇实验的基础进行的
1、在server2上上传安装包给server3
[root@server2 ~]# lsredis-5.0.3 redis-5.0.3.tar.gz[root@server2 ~]# scp redis-5.0.3.tar.gz server3:
2、在server3上解压安装包,安装gcc并编译
[root@server3 ~]# lsredis-5.0.3.tar.gz[root@server3 ~]# tar zxf redis-5.0.3.tar.gz [root@server3 ~]# lsredis-5.0.3 redis-5.0.3.tar.gz[root@server3 ~]# cd redis-5.0.3/[root@server3 redis-5.0.3]# ls[root@server3 redis-5.0.3]# yum install -y gcc && make && make install
3、在utils的目录下执行install.sh的文件
[root@server3 redis-5.0.3]# ls[root@server3 redis-5.0.3]# cd utils/[root@server3 utils]# ls[root@server3 utils]# ./install_server.sh
4、查看端口,发现了6379的端口
[root@server3 utils]# netstat -antlp
5、在utils的目录下修改.conf文件,实现主从复制
[root@server3 redis-5.0.3]# ls[root@server3 redis-5.0.3]# cd utils/[root@server3 utils]# ls[root@server3 utils]# vim /etc/redis/6379.conf bind 0.0.0.0replicaof 172.25.35.1 6379[root@server3 utils]# /etc/init.d/redis_6379 restart
6、重启redis的服务
[root@server3 utils]# /etc/init.d/redis_6379 restart
7、查看redis的信息(此时master是server1,salve是server2和server3)
到此为止,我已经实现了一主(server1)二从(server2、server3)的主从复制
接下来实现哨兵模式
也就是master坏了,从master的所有slave中选举出一个新的master出来
配置redis高可用步骤:
1、将sentinel配置文件拷贝到/etc/redis目录中并编辑
[root@server1 ~]# cd redis-5.0.3/[root@server1 redis-5.0.3]# ls[root@server1 redis-5.0.3]# cp sentinel.conf /etc/redis[root@server1 redis-5.0.3]# cd /etc/redis/[root@server1 redis]# ls6379.conf sentinel.conf[root@server1 redis]# vim sentinel.conf 17 protected-mode no84 sentinel monitor mymaster 172.25.35.1 6379 2113 sentinel down-after-milliseconds mymaster 10000
2、为了方便,将server1配置好的sentinel配置文件发送到server2(注意:发送一定要在server1开启sentinel之前,若果开启之后再发送,sentinel配置文件就不会发生改变,这时再启动sentinel会报错)
[root@server1 redis]# scp sentinel.conf server2:/etc/redis[root@server1 redis]# scp sentinel.conf server3:/etc/redis[root@server1 redis]# redis-cli127.0.0.1:6379> info
3、分别在server1、server2、server3开启sentinel服务
server1主机:
[root@server1 ~]# redis-server /etc/redis/sentinel.conf --sentinel
server2主机:
[root@server2 ~]# redis-server /etc/redis/sentinel.conf --sentinel
4、测试
由于前面的终端被sentinel的开启占用,重新打开一个server1的终端并shutdown模拟master坏掉
[root@server1 redis]# redis-cli ###新的shell127.0.0.1:6379> info127.0.0.1:6379> shutdown
此时我们可以看到变化的过程,虽然主从复制坏了,但sentinel没坏
server1主机变化:
server2的变化:
远程登陆,查看redis主从复制的状态,发现server2通过选举变成了master,server3为从
[root@server1 ~]# redis-cli -h 172.25.35.2
将server1恢复,加入主从复制(由于server1现在是slave,所以需要配置)并重启
[root@server1 ~]# vim /tc/redis/6379.confreplicaof 172.25.35.3 6379[root@server1 ~]# /etc/init.d/redis_6379 restart
重新查看redis的主从复制状态,发现server1作为slave已经加入了主从复制