一、哨兵介绍
Redis Sentinel,即Redis哨兵,在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。下面是Redis官方文档对于哨兵功能的描述:
- 监控(Monitoring):哨兵会不断地检查主节点和从节点是否运作正常。
- 自动故障转移(Automatic failover):当主节点不能正常工作时,哨兵会开始自动故障转移操作,它会将失效主节点的其中一个从节点升级为新的主节点,并让其他从节点改为复制新的主节点。
- 配置提供者(Configuration provider):客户端在初始化时,通过连接哨兵来获得当前Redis服务的主节点地址。
- 通知(Notification):哨兵可以将故障转移的结果发送给客户端。
简单来说,主从模式下为了使主从具备高可用性,就需要用哨兵进行监控,在主节点下线后,会通过投票选出新的主节点,在主节点上线后,也只能作为新节点的从节点。哨兵环境也需要高可用,所以一般是三个以上的集群。
架构图如下:
二、哨兵集群搭建
2.1搭建Redis主从集群
方法请看上一篇博客,redis主从集群搭建。
不同的是我在三个配置文件加了访问密码,requirepass “XXX”,所以需要在这里也加上master的密码
masterauth “XXX”,否则主服务器会拒绝从服务器的复制请求。
2.2修改哨兵配置文件
默认的配置文件是sentinel.conf在主目录下,首先复制两份出来
cp sentinel.conf sentinel-27000.conf
cp sentinel.conf sentinel-27001.conf
然后要修改的内容如下(相同的省略):
sentinel.conf | sentinel-27000.conf | sentinel-27001.conf |
---|---|---|
port 26379 | port 27000 | port 27001 |
pidfile “/var/run/redis-sentinel.pid” | pidfile “/var/run/redis-sentinel2.pid” | pidfile “/var/run/redis-sentinel3.pid” |
sentinel monitor mymaster 127.0.0.1 6379 2 | sentinel monitor mymaster 127.0.0.1 6379 2 | sentinel monitor mymaster 127.0.0.1 6379 2 |
sentinel down-after-milliseconds mymaster 3000 | 略 | 略 |
sentinel failover-timeout mymaster 10000 | 略 | 略 |
sentinel auth-pass mymaster XXX | 略 | 略 |
sentinel myid xxx | sentinel myid xxx | sentinel myid xxx |
注意:
- 如果主服务器使用了密码认证,则sentinel auth-pass mymaster XXX是必须的,并且密码与上面的要一致。
- sentinel monitor mymaster 的配置必须要在 其他用到<master-name>的前面,因为读取配置文件时按顺序读取的会报这个名称未定义(坑了我好久)
- 修改 sentinel myid 从而保证三个id都不同。
- 需要在防火墙开启26379、 27000、 27001三个端口。
2.3启动
- 启动redis主从集群,注意顺序是先master再slave
src/redis-server redis-6379.conf
src/redis-server redis-6380.conf
src/redis-server redis-6381.conf
- 启动哨兵有两种方式。
src/redis-sentinel sentinel.conf
src/redis-server sentinel.conf –sentinel
src/redis-sentinel sentinel.conf
src/redis-sentinel sentinel-27000.conf
src/redis-sentinel sentinel-27001.conf
- 如图,哨兵成功监视了master并发现了下面的两个从服务器
2.4测试故障自动转移
- 查看哨兵集群情况,输入命令src/redis-cli -p 27000再info Sentinel
可以看到master是端口6379的,有两个slaves,三个哨兵。 - 这时我们kill掉6379的Redis进程后,再查看集群情况。哨兵日志如下:
6379挂了后进行了一轮的选举投票,最后6380端口的成为了新的master,来看看现在的集群情况是不是这样的。
- 这时如果重新启动6379,它还会不会恢复老大的身份呢?
5020:X 26 Dec 2018 13:46:38.998 # -sdown slave 8.9.8.165:6379 8.9.8.165 6379 @ mymaster 8.9.8.165 6380
5020:X 26 Dec 2018 13:46:48.947 * +convert-to-slave slave 8.9.8.165:6379 8.9.8.165 6379 @ mymaster 8.9.8.165 6380
日志显示6379重新加入了集群,只不过变成了从服务器。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/13236.html