Docker-Compose部署Redis(v7.2)哨兵模式

最新推荐文章于 2024-02-23 16:22:51 发布

木子dn

最新推荐文章于 2024-02-23 16:22:51 发布

阅读量1.6k

点赞数 21

分类专栏：中间件 # Redis 文章标签： docker redis 容器

本文链接：https://blog.csdn.net/m0_51390969/article/details/135413933

版权

中间件同时被 2 个专栏收录

30 篇文章 1 订阅

订阅专栏

Redis

9 篇文章 0 订阅

订阅专栏

文章目录

一、前提准备
- - 1. 主从集群
  - 2. 文件夹结构
二、配置文件
三、运行
四、测试

环境

docker desktop for windows 4.23.0
redis 7.2

一、前提准备

1. 主从集群

首先需要有一个redis主从集群，才能接着做redis哨兵。具体可以参考下面这篇文章
Docker-Compose部署Redis(v7.2)主从模式(之后简称"主从模式博文")

2. 文件夹结构

和主从模式不同的是，redis sentinel（哨兵）会更改你的conf文件，无论是redis server节点还是sentinel节点本身，都可能被修改，所以这里需要注意文件权限问题。不然会一直警告Sentinel was not able to save the new configuration on disk。

有兴趣可以参考以下几个帖子，或者接着本文做就行了。

总的来说，需要对主从模式博文里提到的文件夹结构做一定改善和添加，具体如下：

cluster/
├── docker-compose.yaml
├── master
│   └── conf
│       └── redis.conf
├── replica1
│   └── conf
│       └── redis.conf
├── replica2
│   └── conf
│       └── redis.conf
├── sentinel1
│   └── conf
│       └── sentinel.conf
├── sentinel2
│   └── conf
│       └── sentinel.conf
└── sentinel3
    └── conf
        └── sentinel.conf

其中redis.conf和docker-compose.yaml和主从模式博文内容暂时保持一致，其余的都是新增的，暂时保持空白即可。

二、配置文件

1. redis server配置文件

保持不变

2. redis sentinel配置文件

对于上述三个sentinel.conf内容都填入以下

sentinel monitor mymaster 172.30.1.2 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel auth-pass mymaster 1009
dir "/data"

意思分别是

监控的主节点：通过 sentinel monitor 指定要监控的主节点。这包括一个用户定义的名称（如 mymaster）、主节点的地址、端口号和一个“仲裁”阈值，后者表示要进行故障转移所需的最小 Sentinel 投票数量。
故障检测：设置 Sentinel 判断主节点是否下线所需的时间
故障转移设置：配置故障转移的行为，如故障转移的超时时间
认证密码（如果主节点设置了密码）：如果主节点设置了密码，Sentinel 需要这个密码来连接主节点和副本节点
设置 Sentinel 的工作目录

3. docker compose文件

version: '3.8'

networks:
  redis-network:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.30.1.0/24

services:
  redis-master:
    container_name: redis-master
    image: redis:7.2
    volumes:
      - ./master/conf:/usr/local/etc/redis
#      - ./master/data:/data
    ports:
      - "7001:6379"
    command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
    networks:
      redis-network:
        ipv4_address: 172.30.1.2

  redis-replica1:
    container_name: redis-replica1
    image: redis:7.2
    volumes:
      - ./replica1/conf:/usr/local/etc/redis
#      - ./replica1/data:/data
    ports:
      - "7002:6379"
    command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
    depends_on:
      - redis-master
    networks:
      redis-network:
        ipv4_address: 172.30.1.3

  redis-replica2:
    container_name: redis-replica2
    image: redis:7.2
    volumes:
      - ./replica2/conf:/usr/local/etc/redis
#      - ./replica2/data:/data
    ports:
      - "7003:6379"
    command: ["redis-server", "/usr/local/etc/redis/redis.conf"]
    depends_on:
      - redis-master
    networks:
      redis-network:
        ipv4_address: 172.30.1.4

  redis-sentinel1:
    container_name: redis-sentinel1
    image: redis:7.2
    volumes:
      - ./sentinel1/conf:/usr/local/etc/redis
    ports:
      - "27001:26379"
    command: ["redis-sentinel", "/usr/local/etc/redis/sentinel.conf"]
    depends_on:
      - redis-master
    networks:
      redis-network:
        ipv4_address: 172.30.1.11

  redis-sentinel2:
    container_name: redis-sentinel2
    image: redis:7.2
    volumes:
      - ./sentinel2/conf:/usr/local/etc/redis
    ports:
      - "27002:26379"
    command: [ "redis-sentinel", "/usr/local/etc/redis/sentinel.conf" ]
    depends_on:
      - redis-master
    networks:
      redis-network:
        ipv4_address: 172.30.1.12

  redis-sentinel3:
    container_name: redis-sentinel3
    image: redis:7.2
    volumes:
      - ./sentinel3/conf:/usr/local/etc/redis
    ports:
      - "27003:26379"
    command: [ "redis-sentinel", "/usr/local/etc/redis/sentinel.conf" ]
    depends_on:
      - redis-master
    networks:
      redis-network:
        ipv4_address: 172.30.1.13

需要注意以下几点

和主从模式博文不同，这里所有的配置文件挂载都采用文件夹挂载而非单文件挂载
这里自定义了bridge子网并限定了范围，如果该范围已经被使用，请更换。
这里没有对data进行-v挂载，如果要挂载，请注意宿主机对应文件夹权限问题。
主节点地址为172.30.1.2，如果更改请注意sentinel.conf中也需要更改。

三、运行

在运行之前，记得备份一下所有的conf文件，因为sentinel会修改挂载到容器的conf。

docker-compose -p redis-cluster up -d

在这里插入图片描述
查看其中一个sentinel节点的日志，可以看到监听端口是26379，同时监测主节点mymaster 172.30.1.2 6379，以及添加了172.30.1.4 6379和172.30.1.3 6379两个从节点，并且感应到了位于172.30.1.13 26379和172.30.1.12 26379两个同为sentinel节点的服务。

2024-01-05 18:06:40 1:X 05 Jan 2024 10:06:40.758 * Running mode=sentinel, port=26379.
2024-01-05 18:06:40 1:X 05 Jan 2024 10:06:40.789 * Sentinel new configuration saved on disk
2024-01-05 18:06:40 1:X 05 Jan 2024 10:06:40.790 * Sentinel ID is 499007c98c0a165b13e026a4443ceb890695c191
2024-01-05 18:06:40 1:X 05 Jan 2024 10:06:40.790 # +monitor master mymaster 172.30.1.2 6379 quorum 2
2024-01-05 18:06:40 1:X 05 Jan 2024 10:06:40.791 * +slave slave 172.30.1.4:6379 172.30.1.4 6379 @ mymaster 172.30.1.2 6379
2024-01-05 18:06:40 1:X 05 Jan 2024 10:06:40.815 * Sentinel new configuration saved on disk
2024-01-05 18:06:42 1:X 05 Jan 2024 10:06:42.055 * +sentinel sentinel bcfaed15fb01e7ad03b013fe5e964479c1a1f138 172.30.1.13 26379 @ mymaster 172.30.1.2 6379
2024-01-05 18:06:42 1:X 05 Jan 2024 10:06:42.093 * Sentinel new configuration saved on disk
2024-01-05 18:06:42 1:X 05 Jan 2024 10:06:42.356 * +sentinel sentinel 92d9a1419be1256d1715df2aa17cea4bbacfdf60 172.30.1.12 26379 @ mymaster 172.30.1.2 6379
2024-01-05 18:06:42 1:X 05 Jan 2024 10:06:42.376 * Sentinel new configuration saved on disk
2024-01-05 18:06:50 1:X 05 Jan 2024 10:06:50.823 * +slave slave 172.30.1.3:6379 172.30.1.3 6379 @ mymaster 172.30.1.2 6379
2024-01-05 18:06:50 1:X 05 Jan 2024 10:06:50.837 * Sentinel new configuration saved on disk

四、测试

直接让redis-master容器停止运行，查看sentinel日志，可以看到sentinel监测到master节点挂掉后，选举了172.30.1.3为新的主节点，并将其余两个作为slave节点。

2024-01-05 18:10:08 1:X 05 Jan 2024 10:10:08.896 # +sdown master mymaster 172.30.1.2 6379
2024-01-05 18:10:08 1:X 05 Jan 2024 10:10:08.968 # +odown master mymaster 172.30.1.2 6379 #quorum 2/2
2024-01-05 18:10:08 1:X 05 Jan 2024 10:10:08.968 # +new-epoch 1
2024-01-05 18:10:08 1:X 05 Jan 2024 10:10:08.968 # +try-failover master mymaster 172.30.1.2 6379
2024-01-05 18:10:08 1:X 05 Jan 2024 10:10:08.987 * Sentinel new configuration saved on disk
2024-01-05 18:10:08 1:X 05 Jan 2024 10:10:08.987 # +vote-for-leader 499007c98c0a165b13e026a4443ceb890695c191 1
2024-01-05 18:10:08 1:X 05 Jan 2024 10:10:08.990 * 92d9a1419be1256d1715df2aa17cea4bbacfdf60 voted for 92d9a1419be1256d1715df2aa17cea4bbacfdf60 1
2024-01-05 18:10:09 1:X 05 Jan 2024 10:10:09.021 * bcfaed15fb01e7ad03b013fe5e964479c1a1f138 voted for 499007c98c0a165b13e026a4443ceb890695c191 1
2024-01-05 18:10:09 1:X 05 Jan 2024 10:10:09.054 # +elected-leader master mymaster 172.30.1.2 6379
2024-01-05 18:10:09 1:X 05 Jan 2024 10:10:09.054 # +failover-state-select-slave master mymaster 172.30.1.2 6379
2024-01-05 18:10:09 1:X 05 Jan 2024 10:10:09.125 # +selected-slave slave 172.30.1.3:6379 172.30.1.3 6379 @ mymaster 172.30.1.2 6379
2024-01-05 18:10:09 1:X 05 Jan 2024 10:10:09.125 * +failover-state-send-slaveof-noone slave 172.30.1.3:6379 172.30.1.3 6379 @ mymaster 172.30.1.2 6379
2024-01-05 18:10:09 1:X 05 Jan 2024 10:10:09.209 * +failover-state-wait-promotion slave 172.30.1.3:6379 172.30.1.3 6379 @ mymaster 172.30.1.2 6379
2024-01-05 18:10:10 1:X 05 Jan 2024 10:10:10.033 * Sentinel new configuration saved on disk
2024-01-05 18:10:10 1:X 05 Jan 2024 10:10:10.033 # +promoted-slave slave 172.30.1.3:6379 172.30.1.3 6379 @ mymaster 172.30.1.2 6379
2024-01-05 18:10:10 1:X 05 Jan 2024 10:10:10.033 # +failover-state-reconf-slaves master mymaster 172.30.1.2 6379
2024-01-05 18:10:10 1:X 05 Jan 2024 10:10:10.094 * +slave-reconf-sent slave 172.30.1.4:6379 172.30.1.4 6379 @ mymaster 172.30.1.2 6379
2024-01-05 18:10:10 1:X 05 Jan 2024 10:10:10.262 * +slave-reconf-inprog slave 172.30.1.4:6379 172.30.1.4 6379 @ mymaster 172.30.1.2 6379
2024-01-05 18:10:10 1:X 05 Jan 2024 10:10:10.262 * +slave-reconf-done slave 172.30.1.4:6379 172.30.1.4 6379 @ mymaster 172.30.1.2 6379
2024-01-05 18:10:10 1:X 05 Jan 2024 10:10:10.338 # +failover-end master mymaster 172.30.1.2 6379
2024-01-05 18:10:10 1:X 05 Jan 2024 10:10:10.338 # +switch-master mymaster 172.30.1.2 6379 172.30.1.3 6379
2024-01-05 18:10:10 1:X 05 Jan 2024 10:10:10.338 * +slave slave 172.30.1.4:6379 172.30.1.4 6379 @ mymaster 172.30.1.3 6379
2024-01-05 18:10:10 1:X 05 Jan 2024 10:10:10.338 * +slave slave 172.30.1.2:6379 172.30.1.2 6379 @ mymaster 172.30.1.3 6379
2024-01-05 18:10:10 1:X 05 Jan 2024 10:10:10.373 * Sentinel new configuration saved on disk

接着让我们看看172.30.1.3的日志，也就是redis-replica1的日志，可以看到与主节点连接失败后，它开启了主节点模式MASTER MODE enabled。

2024-01-05 18:10:03 1:S 05 Jan 2024 10:10:03.812 * Reconnecting to MASTER 172.30.1.2:6379
2024-01-05 18:10:03 1:S 05 Jan 2024 10:10:03.813 * MASTER <-> REPLICA sync started
2024-01-05 18:10:03 1:S 05 Jan 2024 10:10:03.813 # Error condition on socket for SYNC: Connection refused
2024-01-05 18:10:04 1:S 05 Jan 2024 10:10:04.582 * Connecting to MASTER 172.30.1.2:6379
2024-01-05 18:10:04 1:S 05 Jan 2024 10:10:04.582 * MASTER <-> REPLICA sync started
2024-01-05 18:10:09 1:M 05 Jan 2024 10:10:09.209 * Discarding previously cached master state.
2024-01-05 18:10:09 1:M 05 Jan 2024 10:10:09.209 * Setting secondary replication ID to 5032654a1279c56d758c93a4eb1c4b89c99975a9, valid up to offset: 40756. New replication ID is d3464601d550e1159d91234567a366fa1f1a0b5e
2024-01-05 18:10:09 1:M 05 Jan 2024 10:10:09.209 * MASTER MODE enabled (user request from 'id=8 addr=172.30.1.11:55710 laddr=172.30.1.3:6379 fd=13 name=sentinel-499007c9-cmd age=199 idle=0 flags=x db=0 sub=0 psub=0 ssub=0 multi=4 qbuf=188 qbuf-free=20286 argv-mem=4 multi-mem=169 rbs=2048 rbp=1024 obl=45 oll=0 omem=0 tot-mem=23717 events=r cmd=exec user=default redir=-1 resp=2 lib-name= lib-ver=')
2024-01-05 18:10:09 1:M 05 Jan 2024 10:10:09.229 * CONFIG REWRITE executed with success.
2024-01-05 18:10:10 1:M 05 Jan 2024 10:10:10.120 * Replica 172.30.1.4:6379 asks for synchronization
2024-01-05 18:10:10 1:M 05 Jan 2024 10:10:10.120 * Partial resynchronization request from 172.30.1.4:6379 accepted. Sending 567 bytes of backlog starting from offset 40756.

并且还有redis-replica2的日志，里面会显示将数据同步请求地址变成了172.30.1.3而不是先前的172.30.1.2。

接着连接redis-replica1容器看看，发现这个节点以前作为从节点时是只读节点，现在可以写入数据了。

root@1eefea35001f:/data# redis-cli 
127.0.0.1:6379> auth 1009
OK
127.0.0.1:6379> set num 8766
OK
127.0.0.1:6379> get num
"8766"

并且会发现另外两个节点变成只读了，同时，即使先前的主节点又恢复正常了，它不会去夺回master地位。

测试成功。