redis 一主多从 + sentinel哨兵模式

发布时间：2021-10-30作者：laosun阅读（898）

为了更清晰的观察操作步骤已经模拟演示，这里我们使用四台机器，来模拟redis 一主多从+哨兵模式。

四台机器如下：
192.168.0.121 redis-master
192.168.0.122 redis-slave
192.168.0.123 redis-slave
192.168.0.124 redis-sentinel

首先我们根据另一篇文章先搭建好主从复制模式：redis 主从复制模式

如果按照上边四台机器进行搭建，主从复制模式是使用192.168.0.121作为master，192.168.0.122作为slave，那么我们现在只需要在192.168.0.123机器上再搭建一台slave节点即可。搭建方式请参考192.168.0.122。

现在我们全部启动，并且进行测试一主两从复制模式是否正常。若正常，则继续下边的步骤，若不正常，请参考 redis 主从复制模式 继续搭建。

现在进入docker redis 容器内，查看一下Redis的角色。

使用指令为：

# 进入docker redis容器内
docker exec -it redis bash
# 使用redis-cli进行登录
redis-cli -a redis@11..
# 查看详情
info replication

操作方式如下图所示：







从上边三张图我们得知，服务一切正常，121机器是master，其余两台机器都是slave。




---




现在我们使用192.168.0.124机器来部署哨兵服务（部署三个哨兵）

首先根据redis版本下载好sentinel.conf配置文件(和redis.conf在一块，网上下载即可)，最好和当前使用的redis版本一一对应，避免出现不必要的麻烦。

下载完成后我们修改其中几个选项，如下所示：

# 不可设置为yes，否则将会导致docker容器中无法启动
daemonize no
# mymaster 随便弄
# 192.168.0.121 表示redis master的ip，不可使用host别名
# 6379 表示redis master的端口
# 2 表示 需要几个哨兵进行决策，尽量别设置为1，设置为1，表示一个哨兵即可决定你的redis服务的是否正常可用，有些风险。
sentinel monitor mymaster 192.168.0.121 6379 2

# mymaster 和上边保持一致
# redis密码 
sentinel auth-pass mymaster redis密码

完整文件如下（redis 6.2.6版本的conf文件）：

sentinel.conf.zip

docker-compose yaml启动文件如下：

version: '3.9'
services:
 redis-sentinel01:
  image: redis:latest
  container_name: redis-sentinel01
  restart: always
  command: redis-sentinel /etc/sentinel.conf
  ports:
   - 26379:26379
  volumes:
   - ../redis/sentinel.conf:/etc/sentinel.conf
 redis-sentinel02:
  image: redis:latest
  container_name: redis-sentinel02
  restart: always
  command: redis-sentinel /etc/sentinel.conf
  ports:
   - 26380:26379
  volumes:
   - ../redis/sentinel.conf:/etc/sentinel.conf
 redis-sentinel03:
  image: redis:latest
  container_name: redis-sentinel03
  restart: always
  command: redis-sentinel /etc/sentinel.conf
  ports:
   - 26381:26379
  volumes:
   - ../redis/sentinel.conf:/etc/sentinel.conf

下边我们启动后，查看docker 进程，表示已经全部启动成功了。



截止到目前为止，一主两从，以及三个哨兵模式已经全部在运行当中了。







故障模拟

现在我们停止掉192.168.0.121机器上的redis master。（停止方式：关机、docker stop redis、或者 docker-compose -f xxxx.yml down 都可以）

停止后，我们查看下哨兵的日志输出



192.168.0.123晋升成了master服务，我们进一步去确认一下，在192.168.0.123上我们继续使用info replication命令查看一下角色。



上图显示很清楚，123这台机器已经晋升成了master服务，并且从节点只有一台，为：192.168.0.122

截止到目前为止，故障自动切换已经完成，模拟停止192.168.0.123这台master机器也可以，最后仅剩的一台192.168.0.122将成为master。这里就不进行演示了。







故障恢复

所谓的故障恢复就是将故障机器上的redis服务重新启动，加入到redis集群中。

现在机器情况

192.168.0.121 宕机
192.168.0.122 redis-slave(正常)
192.168.0.123 redis-master(正常)
192.168.0.124 redis-sentinel(正常)

现在我们重新启动192.168.0.121上的redis服务就会自动加入redis集群吗？

答案

NO

回忆一下：还记得主/从节点redis的配置文件嘛？

# 增加和修改以下内容
slaveof 主redis的ip 主端口
masterauth 主redis的密码

现在192.168.0.121这台机器的配置文件是master配置文件，如果此时启动，是不能加入到redis集群中。

有的人就提出了是不是需要修改redis.conf，然后将master的配置修改成slave的配置，这个方法固然可以，如果所有的redis机器都需要停止呢，然后重启呢，是不是还得重新修改配置一遍。太麻烦了。先看下以下错误的修改方法吧！

错误的配置方式（不建议尝试，看下就可以了）：

修改redis.conf，将上边的内容重新配置一下，配置成slave节点。现在我们已知192.168.0.123是master节点，那么就配置成123这台机器即可。现在我们修改一下，重新启动192.168.0.121上的redis从节点。启动成功后，如下图所示：



正确的配置方式：

我们先启动192.168.0.121这个已经宕机的机器（启动之前不需要修改配置文件），启动成功后，我们使用redis-cli进入redis 客户端控制台

如下所示：

# 因为博主是docker部署，所以先进入容器
docker exec -it redis bash

redis-cli -a redis@11..

操作到此以后，我们先看下这台已经重新启动的master机器是否自动作为slave节点，答案是并没有。

那么我们继续以下操作

# 临时修改配置文件，指向新的主节点，设置主节点的密码
config set masterauth redis@11..
# 指向主节点链接方式
slaveof 192.168.0.123 6379

然后设置完成后，这台原本是master的已经宕机的机器，启动后成为了新的slave节点，并且数据已经开始同步。

注：重启已经宕机的不论是master节点或者slave节点任何节点，都需要启动成功后使用以上两个指令临时重新配置指向新的机器。

截止到目前为止，redis一主多从+哨兵模式已经配置完成。

 发表评论

 请文明留言

  发表

共 0 条评论