一篇博客教会你使用Docker部署Redis哨兵

今天我们学习使用 Docker 部署 Redis 的主从复制，并部署 Redis 哨兵，实现 Redis 数据库的高可用。

主数据库

如何使用 Docker 下载并启动一个 Redis 实例，我们在以前的博客 《一篇博客教会你怎么使用Docker安装Redis》 学习过，在本篇博客中就不过多赘述，有兴趣的同学可以移步到之前的博客学习。

配置文件

我们先将准备好的配置文件复制一份。

script

cp redis.conf redis-master.conf

启动实例

然后使用 Docker 命令，启动一个 Redis 数据库实例作为主数据库。

script

docker run -p 6380:6379 --name redis-master -v /etc/redis/redis-master.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf

容器虚拟IP

使用 Docker 命令，获取 Redis 实例的虚拟 ip 地址

script

docker inspect --format={{.NetworkSettings.IPAddress}} redis-master

从数据库

从数据相比较于主数据，需要配置从数据库对应的主数据的信息，即主数据的 ip 和端口，其中的 ip 即上述使用 Docker 命令获取的虚拟 ip 地址，而端口同样也是容器对应的虚拟端口，即为 Docker 容器内部对应的 6379，而不是容器外部的映射端口。

配置文件

将配置文件复制一份，作为从数据库的配置文件。

script

cp redis.conf redis-slave.conf

在 redis-slave.conf 配置文件的末尾添加主数据库的信息配置。

script

REPLICAOF 172.17.0.2 6379

启动实例

然后使用 Docker 命令，启动三个 Redis 数据库实例作为从数据库。

script

docker run -p 6381:6379 --name redis-slave1 -v /etc/redis/redis-slave.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf

docker run -p 6382:6379 --name redis-slave2 -v /etc/redis/redis-slave.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf

docker run -p 6383:6379 --name redis-slave3 -v /etc/redis/redis-slave.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf

主从数据库

我们可以使用 Docker 命令进入 Redis 的四个实例中，查看主从关系是否生效。

查看主数据库

使用命令查看主数据库的情况，从图中我们可以确认，该 Redis 实例为主数据库，共有三个从数据库。

script

docker exec -it redis-master bash

redis-cli

info Replication

查看从数据库

使用命令查看从数据库的情况，从图中我们可以确认，该 Redis 实例为从数据库及该从数据库对应的主数据库的具体信息。

script

docker exec -it redis-slave1 bash

redis-cli

info Replication

哨兵

我们使用 Docker 启动 Redis 实例作为哨兵。

配置文件

创建 sentinel.conf 文件，并在文件内编辑配置文件内容如下：

script

# 哨兵sentinel实例运行的端口 默认26379 
port 26379 
# 哨兵sentinel的工作目录 
dir /tmp 
# 哨兵sentinel监控的redis主节点的 ip port 
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组 成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点 失联了 
# sentinel monitor <master-name> <ip> <redis-port> <quorum> 
sentinel monitor redis-master 172.17.0.2 6379 2
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都 要提供密码 
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码 
# sentinel auth-pass <master-name> <password> 
sentinel auth-pass redis-master ""
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒 
# sentinel down-after-milliseconds <master-name> <milliseconds> 
sentinel down-after-milliseconds redis-master 30000 
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步
# 这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。 
# 可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。 
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs redis-master 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 redis-master 180000


# SCRIPTS EXECUTION 
# 配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮 件通知相关人员。 
#对于脚本的运行结果有以下规则： 
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10 
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。 
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。 
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执 行。

#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等 等），将会去调用这个脚本，
#这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正 常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。 
#如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且 是可执行的，否则sentinel无法正常启动成功。

#通知脚本 
# sentinel notification-script <master-name> <script-path> 
# sentinel notification-script mymaster /var/redis/notify.sh

# 客户端重新配置主节点参数脚本 
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master 地址已经发生改变的信息。 
# 以下参数将会在调用脚本时传给脚本: 
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port> 
# 目前<state>总是“failover”, 
# <role>是“leader”或者“observer”中的一个。 
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的 slave)通信的 
# 这个脚本应该是通用的，能被多次调用，不是针对性的。 
# sentinel client-reconfig-script <master-name> <script-path> 
# sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

哨兵的配置文件内容较多，需要注意以下几点：

• sentinel monitor redis-master 172.17.0.2 6379 2
  该配置为 Redis 主数据库的 ip 和端口，需要将其修改为自己启动的 Redis 主数据库的 ip 和端口。
  最后一个参数为哨兵投票成功的个数，不要大于哨兵的总实例个数。

• sentinel auth-pass redis-master “”
  该配置为 Redis 主数据库的密码，如果没有，使用空串即可；如果有，需要配置密码，注意必须为主从数据库设置一样的验证密码

• sentinel down-after-milliseconds redis-master 30000
  该配置为哨兵认为主数据库下线的时间，即主数据库下线或宕机之后 30000 毫秒，哨兵会主观认为主数据库真正下线。

启动哨兵

然后使用 Docker 命令，启动三个 Redis 数据库实例作为哨兵。

script

docker run -p 26379:26379 --name redis-sentinel1 -v /etc/redis/sentinel.conf:/etc/redis/sentinel.conf -d redis redis-sentinel /etc/redis/sentinel.conf

docker run -p 26380:26379 --name redis-sentinel2 -v /etc/redis/sentinel.conf:/etc/redis/sentinel.conf -d redis redis-sentinel /etc/redis/sentinel.conf

docker run -p 26381:26379 --name redis-sentinel3 -v /etc/redis/sentinel.conf:/etc/redis/sentinel.conf -d redis redis-sentinel /etc/redis/sentinel.conf

查看哨兵

使用命令查看哨兵的情况，从图中我们可以确认，该 Redis 哨兵已经启动成功，并获取了主数据库，从数据库，其他哨兵的信息。

script

docker logs -f redis-sentinel1

或者我们可以使用其他命令，进入哨兵实例的内部，查看实例信息，从图中我们可以看出，该 Redis 哨兵启动状态成功，其中有主数据库地址为 172.17.0.2:6379，从数据库3个，哨兵3个。

script

docker exec -it redis-sentinel1 bash

redis-cli -p 26379

info Sentinel

哨兵机制

哨兵选举

我们使用 Docker 将 Redis 主数据库实例停止运行，模拟出主数据库因为意外情况下线或者宕机的情况。

script

docker stop redis-master

等候大约 30000 毫秒左右的时间，我们重新查看哨兵的情况。

script

docker exec -it redis-sentinel1 bash

redis-cli -p 26379

info Sentinel

第一个 info Sentinel 是因为时间还没有达到 30000 毫秒之后，哨兵还没有主观判断主数据库下线，而等候 30000 毫秒之后，数据库下线，于是哨兵自动从 3 个从数据库中选举了一个作为新的主数据库。

选举日志

我们可以使用命令查看日志，查看哨兵的选举过程。

script

docker logs -f redis-sentinel1

日志解读：

script

# 主数据库 172.17.0.2 6379 下线了
1:X 26 Jun 2023 13:46:29.680 # +sdown master redis-master 172.17.0.2 6379
1:X 26 Jun 2023 13:46:29.823 # Could not rename tmp config file (Device or resource busy)
1:X 26 Jun 2023 13:46:29.823 # WARNING: Sentinel was not able to save the new configuration on disk!!!: Device or resource busy
1:X 26 Jun 2023 13:46:29.823 # +new-epoch 1
1:X 26 Jun 2023 13:46:29.825 # Could not rename tmp config file (Device or resource busy)
1:X 26 Jun 2023 13:46:29.825 # WARNING: Sentinel was not able to save the new configuration on disk!!!: Device or resource busy
1:X 26 Jun 2023 13:46:29.825 # +vote-for-leader 07a74f95d2f3284e2bcbd34bac98b29e527d5878 1
# 等待了 30000 毫秒之后（注意日志时间），3 个哨兵判断主数据库下线，超过了配置的 2 个哨兵，哨兵主观确定主数据库下线
1:X 26 Jun 2023 13:46:30.842 # +odown master redis-master 172.17.0.2 6379 #quorum 3/2
1:X 26 Jun 2023 13:46:30.842 # Next failover delay: I will not start a failover before Mon Jun 26 13:52:29 2023
1:X 26 Jun 2023 13:46:31.039 # +config-update-from sentinel 07a74f95d2f3284e2bcbd34bac98b29e527d5878 172.17.0.8 26379 @ redis-master 172.17.0.2 6379
# 切换已下线的主数据库 172.17.0.2 6379，选举 172.17.0.5 6379 为新的主数据库
1:X 26 Jun 2023 13:46:31.039 # +switch-master redis-master 172.17.0.2 6379 172.17.0.5 6379
# 重新构建主从关系
1:X 26 Jun 2023 13:46:31.040 * +slave slave 172.17.0.4:6379 172.17.0.4 6379 @ redis-master 172.17.0.5 6379
1:X 26 Jun 2023 13:46:31.040 * +slave slave 172.17.0.3:6379 172.17.0.3 6379 @ redis-master 172.17.0.5 6379
# 重新构建主从关系，原本的主数据库 172.17.0.2 6379 被降为从数据库
1:X 26 Jun 2023 13:46:31.040 * +slave slave 172.17.0.2:6379 172.17.0.2 6379 @ redis-master 172.17.0.5 6379
1:X 26 Jun 2023 13:46:31.044 # Could not rename tmp config file (Device or resource busy)
1:X 26 Jun 2023 13:46:31.044 # WARNING: Sentinel was not able to save the new configuration on disk!!!: Device or resource busy
# 从库 172.17.0.2 6379 下线（但是不影响主库和其他从库和哨兵）
1:X 26 Jun 2023 13:47:01.083 # +sdown slave 172.17.0.2:6379 172.17.0.2 6379 @ redis-master 172.17.0.5 6379

重启主数据库

重新启动原本的主数据库

script

docker start redis-master

查看原本的主数据的信息：

script

docker exec -it redis-master bash

redis-cli

info Replication

我们可以看到原本的主数据在宕机后重新启动，已经彻底变成了从数据库。