孤傲的菜单
- Sentinel模式简介
- 测试环境介绍
- Sentinel部署环境流程介绍
- 开始部署
-
-
- 对A机器的操作
- 对B机器的操作
-
- 开始测试
-
-
- 完成设想2
- 完成设想3
-
- 使用keepalived完成哨兵模式
- 需要特别注意防火墙在A、B服务器中的配置
- 更多的命令可参考
Sentinel模式简介
以下描述来自：https://www.cnblogs.com/xintiao-/p/10414742.html
Redis-Sentinel是redis官方推荐的高可用性解决方案，
当用redis作master-slave的高可用时，如果master本身宕机，redis本身或者客户端都没有实现主从切换的功能。
而redis-sentinel就是一个独立运行的进程，用于监控多个master-slave集群，
自动发现master宕机，进行自动切换slave > master。
sentinel主要功能如下：
- 不时的监控redis是否良好运行，如果节点不可达就会对节点进行下线标识
- 如果被标识的是主节点，sentinel就会和其他的sentinel节点“协商”，如果其他节点也人为主节点不可达，就会选举一个sentinel节点来完成自动故障转义
- 在master-slave进行切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换
测试环境介绍
测试环境为centos7.5
A机器ip：10.0.8.37
B机器ip：10.0.8.243
Redis版本：5.0.3
在这之前，我们分别在A机器和B机器上运行Redis服务，此刻他们均为master节点
Sentinel部署环境流程介绍
文字描述还可以参考：https://www.cnblogs.com/kevingrace/p/9004460.html
开始部署
如果你使用是的redis源代码安装形式安装的Redis，那么在解压出来的目录下，有一个名为sentinel.conf的配置文件，该文件就是用来配置sentinel的，拷贝一份，放到~目录下
前提：无故障时A机器Redis充当master节点，B为slave节点（无论是使用.conf写slave节点还是使用redis-cli配置均可）
首先做做一下我们的设想
- 设想2：此时A机器上面的Redis挂掉了，那么B机器此时应当切换为master节点节点
- 设想3：过了一段时间A机器的Redis恢复了，B机器又应该变成slave节点
为了完成上面的设想，先来进行配置，然后再去测试是否成功
对A机器的操作
创建文件夹redis_data
mkdir /home/zeng/redis_data
修改配置文件sentinel.conf
daemonize yes
logfile "26379.log"
dir "/home/zeng/redis_data"
sentinel monitor mymaster 10.0.8.37 6379 2
用
redis-sentinel sentinel.conf
启动A机器上的哨兵
查看一下当前A机器的redis信息
redis-cli info replication
可以看到如下
对B机器的操作
创建文件夹redis_data
mkdir /home/zeng/redis_data
修改配置文件sentinel.conf
daemonize yes
logfile "26379.log"
dir "/home/zeng/redis_data"
sentinel monitor mymaster 10.0.8.37 6379 2
用
redis-sentinel sentinel.conf
启动A机器上的哨兵
注意这里，在A和B机器上，都是同时监听A机器上的redis是否有响应
redis-cli info replication
查看一下当前A机器的Redis信息，再过个几秒运行，发现B机器的Redis从master自动切换成了slave节点
此时设想1已经成功
开始测试
完成设想2
执行
ps -ef|grep redis-server|grep -v grep|awk '{print $2}'|xargs sudo kill -9
命令，退出redis-server
在B机器上用
redis-cli info replication
查看一下当前机器的Redis信息
已经自动切换到了master节点
此时设想2已经成功
完成设想3
此时我们在B机器上设置一个值
在A机器上，重启redis
再次查看A机器上的Redis信息，发现此时，A是B的slave节点，此时也能取出之前设置的值
所以设想3，需要更改一下：
设想3：过了一段时间A机器的Redis恢复了，~~B机器又应该变成slave节点，~~A机器此时会作为B机器的备用节点存在，这样才能使用故障时间内所存储的数据
所以，之前的设想，变成了结论：
- 结论1：无故障时A机器Redis充当master节点，B为slave节点
- 结论2：此时A机器上面的Redis挂掉了，那么B机器此时应当切换为master节点节点
- 结论3：过了一段时间A机器的Redis恢复了，B机器又应该变成slave节点；只有此时B机器出故障，A才又会变成master节点
有兴趣的朋友可以自己动手验证以下以上的步骤
使用keepalived完成哨兵模式
keepalived相对于使用Sentinel来说会比较麻烦，监听的脚本需要自己来写
具体keepalived来做哨兵的实现可以参考：https://www.cnblogs.com/binchen-china/p/5593451.html
因为链接提供gayhub地址中的脚本源码已经找不到，所以你只能按照blog文中的内容来复制粘了
还有其他的keepalived完成哨兵模式有：
使用Python脚本，slave一直ping Redis服务器，如果发现ping不同master，用命令调用
redis-cli slave none
形式来是当前节点变为master节点；如果恢复过来，用命令调用
redis-cli slave ip 6379
变成slave
需要特别注意防火墙在A、B服务器中的配置
务必相互打开6379和26379
更多的命令可参考
官网文档地址：http://redisdoc.com/topic/sentinel.html