前言
在上一篇,我们了解了redis 复制集群的完整的搭建流程,本篇来分享一下如何搭建 redis 哨兵集群。
为什么需要哨兵集群
redis哨兵集群要解决的问题是什么呢?搞清楚这个问题之后,就知道为什么需要哨兵集群了。我们知道,redis复制集群解决的是,高并发情况下,单节点的读性能瓶颈以及单节点问题;
但是复制集群的很明显的问题就是,当主节点挂掉后,集群将无法提供写业务,如果要恢复集群,则需要人工介入,这个必定会丢失数据不说,而且需要一定的时间;
而在哨兵模式下,集群的状态通过哨兵可以得到实时监控,一旦主节点宕机,哨兵会立即感知,然后选举出新的主节点,继续对外提供服务;
搭建前准备
1、基于centos7 的虚拟机(或云服务器);
2、redis 安装包(本篇基于6.X版本);
搭建步骤
本篇的集群将在同一台机器上搭建演示,通过不同的端口进行区分
1、准备(规划)三个sentinel实例
节点 | IP | PORT |
---|---|---|
s1 | 10.34.33.80 | 27001 |
s2 | 10.34.33.80 | 27002 |
s3 | 10.34.33.80 | 27003 |
2、创建3个文件目录
要在同一台虚拟机开启3个实例,必须准备三份不同的配置文件和目录,配置文件所在目录也就是工作目录。我们创建三个文件夹,名字分别叫s1、s2、s3;
mkdir s1 s2 s3
3、在s1目录下创建一个sentinel.conf文件
添加下面的内容:
port 27001
sentinel announce-ip IP
sentinel monitor mymaster IP 7001 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
dir "/tmp/s1"
配置文件解读:
port 27001
:是当前sentinel实例的端口;sentinel monitor mymaster 192.168.150.101 7001 2
:指定主节点信息
mymaster
:主节点名称,自定义,任意写;
IP 7001
:主节点的ip和端口;
2
:选举master时的quorum值
4、将s1/sentinel.conf文件拷贝到s2、s3两个目录中
在/tmp目录执行下列命令
cp s1/sentinel.conf s2
cp s1/sentinel.conf s3
5、修改s2,s3目录下的配置文件端口分别为27002、27003
在tmp目录下执行下面的命令
sed -i -e 's/27001/27002/g' -e 's/s1/s2/g' s2/sentinel.conf
sed -i -e 's/27001/27003/g' -e 's/s1/s3/g' s3/sentinel.conf
随机打开一个s2或s3目录下的文件,可以发现,配置文件已调整;
6、启动3个sentinel实例
在启动sentinel集群之前,先把上一篇的redis集群启动起来
进入到tmp目录,分别执行下面的命令进行启动
# 第1个
redis-sentinel s1/sentinel.conf
# 第2个
redis-sentinel s2/sentinel.conf
# 第3个
redis-sentinel s3/sentinel.conf
启动过程
通过输出日志,也可以看到,三个sentinel实例已经正常启动,并探测到 7001,7002,7003这三个redis实例,以及这三个redis实例的主从关系,即redis集群已经成功被sentinel集群监控起来;
到这里为止,整改哨兵集群大搭建过程就完成了,接下来,做一下集群的异常测试
集群测试
将redis 7001这个服务实例强制下线
在下线的时候,注意分别观察sentinel的3个实例控制台的输出日志变化
从sentinel实例控制台的输出日志来看,主要经历了3个阶段:
- 认为7001这个redis实例主观下线;
- 当sentinel集群超过半数以上的实例认为7001这个节点下线时,变成客观下线;
- 发起投票,在剩下的2个redis实例中进行新的redis master的选举;
再次启动7001这个实例
通过sentinel控制台输出日志,可以看到,7001服务实例信息再次被sentinel集群探测到,即监控起来
需要注意的是,再次启动7001服务之后,7001这个redis实例不一定会再次成为master