Redis哨兵模式配置详解

        主从复制模式，它是属于 Redis 多机运行的基础，但这种模式本身存在一个致命的问题，当主节点奔溃之后，需要人工干预才能恢复 Redis 的正常使用。

        我们需要一个自动的工具——Redis Sentinel（哨兵模式）来把手动的过程变成自动的，让 Redis 拥有自动容灾恢复（failover）的能力。

        哨兵就相当于对主从服务器做一个监视的任务。一旦发现主服务器宕机了，就迅速启动相应的规则将某一台从服务器升级为主服务器，无需人工干预，更稳定更快。

        哨兵模式需要依赖主从复制模式，主从复制模式详解参见我的微博 【Redis主从复制模式配置详解】

        哨兵模式结构图如下：

1、哨兵模式配置

配置哨兵模式的前提是实现了主从复制模式的配置，即一个主服务，2个从服务。

1.1创建哨兵配置文件

最少创建三个哨兵，注意哨兵的数量是奇数。

• 创建哨兵配置文件目录

        在redis 目录（/usr/local/redis-7.2.4）下，创建一个哨兵配置文件目录 sentinel-conf

mkdir sentinel-conf

• 创建第一个哨兵配置文件并修改配置

        在redis目录下，拷贝sentinel.conf到sentinel-conf目录下，命名为sentinel-26381.conf

cp sentinel.conf sentinel-conf/sentinel-26381.conf

修改配置文件sentinel-26381.conf

vim sentinel-26381.conf

修改项目如下：

#修改port
port 26381 

 #开启守护线程
daemonize yes

#进程文件
pidfile /var/run/redis-sentinel-26381.pid

#sentinel monitor <master-group-name> <ip> <port> <quorum>
#master-group-name是集群名称，可以自定义，
#ip：master主机ip地址
#quorum哨兵数量，是需要同意主节点不可用的Sentinel的数量，一般是哨兵数量减1
#比如2表示，当至少有2个哨兵发现master的redis挂了，
#               那么就将此master标记为宕机节点。
#               这个时候就会进行故障的转移，将其中的一个从节点变为master

sentinel monitor mymaster 127.0.0.1 6380 2

如下图：

 

• 创建第二个和第三个哨兵配置文件并修改配置并修改端

cp sentinel-26381.conf sentinel-26382.conf


cp sentinel-26381.conf sentinel-26383.conf

 修改sentinel-26382.conf：

vim sentinel-26382.conf

 修改内容同上，如下图：

 同样修改sentinel-26383.conf

vim sentinel-26383.conf

1.2配置哨兵监听

分别修改vim sentinel-26381.conf、

vim sentinel-26382.conf、

vim sentinel-26383.conf

主要改如下四个配置：

# 第三个参数：哨兵名字，可自行修改。（若修改了，那后面涉及到的都得同步） 
# 第四个参数：master主机ip地址
# 第五个参数：redis端口号
# 第六个参数：哨兵的数量。比如2表示，当至少有2个哨兵发现master的redis挂了，
#               那么就将此master标记为宕机节点。
#               这个时候就会进行故障的转移，将其中的一个从节点变为master
sentinel monitor mymaster 192.168.101.123 7001 2
# master中redis的密码
sentinel auth-pass mymaster 123456
# 哨兵从master节点宕机后，等待多少时间（毫秒），认定master不可用。
# 默认30s，这里为了测试，改成10s
sentinel down-after-milliseconds mymaster 10000
# 当替换主节点后，剩余从节点重新和新master做同步的并行数量，默认为 1
sentinel parallel-syncs mymaster 1
# 主备切换的时间，若在3分钟内没有切换成功，换另一个从节点切换
sentinel failover-timeout mymaster 180000

 修改结果如下：

sentinel-26381.conf

 sentinel-26382.conf

sentinel-26383.conf

2、哨兵模式测试

 先关闭redis所有服务

2.1启动三个主从服务

为了在一台主机上模拟启动三个服务，我们在shell开三个窗口，分别启动主从服务 6380、从服务6381、6382，不在后台启动

主服务 6380

redis-server redis-master.conf

从服务1  6381

redis-server /usr/local/redis-7.2.4/redis-conf/redis-slave1.conf

从服务2 6382

redis-server /usr/local/redis-7.2.4/redis-conf/redis-slave2.conf

 2.2启动哨兵服务

也是为了模拟测试，启动三个不同的shell

启动哨兵一 26381

为了测试，在配置文件中把守护模式改为 no

redis-sentinel /usr/local/redis-7.2.4/sentinel-conf/sentinel-26381.conf

 如果报如下错误，正常启动请忽略:

7790:X 08 Mar 2024 05:35:43.959 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

这是由于  Redis 容器日志中的警告信息指出了内存超分配（overcommit）的设置问题。在 Linux 系统中，内存超分配是一种内核行为，允许进程分配超出物理内存大小的虚拟内存。对于 Redis，这是一个重要的设置，尤其是当执行如 RDB 快照或 AOF 日志重写等内存密集型操作时。

 解决办法：

临时更改（不会在重启后保持）：

在宿主机上执行以下命令：

sudo sysctl vm.overcommit_memory=1

永久更改：

编辑 /etc/sysctl.conf 文件（或在某些系统上，可能是 /etc/sysctl.d/ 目录下的文件）。

添加或修改以下行：

vm.overcommit_memory = 1

保存文件并重新启动系统，或者运行 sudo sysctl -p 来立即应用更改。

启动后如下：

启动后，主服务6380也可以感知到

启动哨兵二 26382

为了测试，在配置文件中把守护模式改为 no

再启动

redis-sentinel /usr/local/redis-7.2.4/sentinel-conf/sentinel-26382.conf

 启动后后，主服务6380也有反应

启动哨兵三26383 

redis-sentinel /usr/local/redis-7.2.4/sentinel-conf/sentinel-26383.conf

 2.3模拟测试

1.模拟强制关闭主服务redis-master 6380

主服务redis-master 6380已经关闭

2. 30秒后，查看哨兵启动窗口，发现主服务从6380 切换到6381

再看从服务，顺利连到6381 

 重启启动强制挂掉的6380

再看6381，已经检测到6380已经连接

再重复一遍，如果挂了6381，则6382显示如下：

 30秒后，又切换到6380

 这样就配置成功了。