redis 哨兵集群搭建
前言
在上一篇，我们了解了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 27001sentinel announce-ip IPsentinel monitor mymaster IP 7001 2sentinel down-after-milliseconds mymaster 5000sentinel failover-timeout mymaster 60000dir "/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 s2cp s1/sentinel.conf s3
5、修改s2，s3目录下的配置文件端口分别为27002、27003
在tmp目录下执行下面的命令
sed -i -e 's/27001/27002/g' -e 's/s1/s2/g' s2/sentinel.confsed -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
我不是女神ヾ
Bertha 。
朱雀
ゞ 浴缸里的玫瑰
「爱情、让人受尽委屈。」
还没有评论，来说两句吧...