Redis哨兵模式简介

哨兵(sentinel)是Redis的高可用性(High Availability)的解决方案: 由一个或多个sentinel实例组成sentinel集群可以监视一个或多个主服务器和多个从服务器。 当主服务器进入下线状态时,sentinel可以将该主服务器下的某一从服务器升级为主服务器继续提供服 务,从而保证redis的高可用性。

每个哨兵(sentinel)都分别独立的监控主服务器和所有的从服务器,各个哨兵之间也互相有通信,主服务器和从服务器之间是主从复制的关系。如下图所示:

Redis哨兵配置实战

接下来我们进行redis哨兵的配置实战。

环境

服务器系统:centos7

环境:本地虚拟机(VMware)

redis版本:5.0.3

此次测试使用了一主两从,三个哨兵(sentinel),主从服务器及哨兵对应的ip分别如下:

master+sentinel: ip:192.168.73.123

slave1+sentine1: ip:192.168.73.9

slave2+sentine2 ip:192.168.73.128

核心配置

主从配置

第一步首先进行主从配置。(可以参照 深入浅出Redis(八)——Redis主从搭建实战 。)

master配置

修改主服务器redis安装路径中的redis.conf文件:

1
2
3
4
5
6
# 将`daemonize`由`no`改为`yes` 允许后台运行
daemonize yes
# 默认绑定的是回环地址,默认不能被其他机器访问
# bind 127.0.0.1
# 是否开启保护模式,由yes该为no
protected-mode no

slave1配置

配置主从,修改redis.conf:

1
replicaof 192.168.73.123 6379

这里的192.168.73.123是主服务器的ip,6379是主服务器的redis端口号。

slave2配置

同slave1,对slave2配置主从,修改redis.conf:

1
replicaof 192.168.73.123 6379

哨兵配置

配置完主从之后,开始配置哨兵。哨兵配置的核心主要是sentinel.conf配置文件。

哨兵1

我们在之前主从模式的基础上新copy出来一份redis,作为哨兵1:

1
 cp -r redis redis-sentinel1

复制redis源文件中的sentinel.conf文件到哨兵redis-sentinel的目录下:

1
cp redis-5.0.3/sentinel.conf /usr/local/redis-sentinel1/bin/

执行命令vim sentinel.conf修改sentinel.conf配置文件:

1
2
3
4
5
6
7
8
9
10
11
12
# 哨兵sentinel实例运行的端口 默认26379
port 26379

#哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 192.168.73.123 6379 2

# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒,改成3秒,方便演示
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 3000

上面的是必须的配置,此外介绍几个可能需要额外配置的地方:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd

# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步,这个数字越小,完成failover所需的时间就越长,但是如果这个数字越大,就意味着越 多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1

# 故障转移的超时时间 failover-timeout 可以用在以下这些方面:
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时,配置所有slaves指向新的master所需的最大时间。不过,即使过了这个超时,slaves依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000

哨兵2

和哨兵1的配置类似。

哨兵3

参考哨兵1的配置。

启动

配置好后依次执行 redis-master、redis-slaver1、redis-slaver2、redis-sentinel1、redis-sentinel2、redis-sentinel3

1
2
3
4
5
6
7
8
#启动redis-master和redis-slaver
在redis-master的安装目录下 ./redis-server redis.conf
在redis-slaver1的安装目录下 ./redis-server redis.conf
在redis-slaver2的安装目录下 ./redis-server redis.conf
#启动redis-sentinel
在redis-sentinel1的安装目录下 ./redis-sentinel sentinel.conf
在redis-sentinel2的安装目录下 ./redis-sentinel sentinel.conf
在redis-sentinel3的安装目录下 ./redis-sentinel sentinel.conf

在都依次启动完成之后,我们可以查看系统中的redis进程:

可以看到同一台虚拟机中运行着redis-server与redis-sentinel两个服务。

测试

先进行主从同步测试,效果图如下:

然后进行哨兵的测试,具体步骤如下:

我们测试将master挂掉,然后会看到slave1和slave2中会任意选择一个升为主,也就是具有写的能力。

如果此时,我们再将原来挂掉的master启动起来,那么会发现原来的master此时只能读不能写,也就是她只能作为从库使用了,因为已经有新的主了。

说明配置没有问题。

总结

我们在之前redis简单主从模式的基础上介绍了redis哨兵模式的配置,以及相应的实战,实现了redis的高可用。