Redis的哨兵

什么是哨兵

顾名思义，哨兵的作用就是对Redis的系统的运行情况的监控，它是一个独立进程。它的功能有2个：

• 1、 监控主数据库和从数据库是否运行正常；
• 2、 主数据出现故障后自动将从数据库转化为主数据库；

单个哨兵

单个哨兵的架构：

当前处于一主多从的环境中：

进入redis安装目录

修改哨兵配置文件

vim sentinel.conf

输入内容：

sentinel monitor mymaster 127.0.0.1 6379 1

说明：

mymaster：监控主数据的名称，自定义即可，可以使用大小写字母和“.-_”符号

127.0.0.1：监控的主数据库的IP

6379：监控的主数据库的端口

1：最低通过票数 将这个主实例判断为失效至少需要 2 个 Sentinel进程的同意，只要同意Sentinel的数量不达标，自动failover就不会执行

启动哨兵进程

由上图可以看到：

1、 哨兵已经启动，它的id为e0ac9b30c5d321e616fbea7ced96d0b4b911b6c3

2、 为master数据库添加了一个监控

3、 发现了2个slave（由此可以看出，哨兵无需配置slave，只需要指定master，哨兵会自动发现slave）

从库宕机

kill掉4054进程后

30秒后.哨兵的控制台 打印出来 +sdown信息

说明已经监控到slave宕机了，那么，如果我们将3381端口的redis实例启动后，会自动加入到主从复制吗？

重启后，哨兵控制台信息：

+reboot：重启。    -sdown：说明是恢复服务。

可以看出，slave从新加入到了主从复制中。

主库宕机

kill掉6379端口的主库

哨兵控制台打印

进入 6381 查看状态

6381 已经是 master了 并且拥有一个 6380的slave

重新启动6379

哨兵控制台:6379已经恢复,并且将6379设置为6381的slave

这时我们查看sentinel.conf 发现  我们刚刚配置的端口已经变成6381

同样的，6381的从库变成，redis.conf的配置文件也会去掉之前从库的设置

查看6379和6380配置

6379之前是没有配置,所以就添加到了最后一行

6380

sentinel后台运行和redis的配置文件一样修改daemonize参数

多个哨兵

配置了一个哨兵,如果该哨兵宕机了,那么整个主从架构就回复到了原始的情况,所以我们可以配置多个哨兵,每个哨兵监控Redis信息,并且哨兵之间也会互相监控

多个哨兵的架构：

主从架构

拷贝一份sentinel.conf

分别修改端口和最低通过票数

分别启动这两个哨兵

从库宕机

kill掉6380端口的redis

两个哨兵控制台分别打印

重启6380的redis之后，两个哨兵控制台分别打印

主库宕机

kill掉主库的redis

同样两个哨兵控制台打印

重启后之后变成从库了

哨兵宕机

哨兵宕机测试始终监控不到 不知道为什么