Redis 哨兵

1. 基本介绍

High availability with Redis Sentinel | Redis

哨兵巡查监控后台 master 主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务

• 哨兵作用

1. 监控 redis 运行状态，包括 master 和 slave

2. 当 master down机，能自动 slave 切换成新 master

2. 作用

• 主从监控：监控主从 redis 库运行是否正常

• 消息通知：哨兵可以将故障转移的结果发送给客户端

• 故障转移：如果 master 正常，则会进行主从切换，将其中一个 Slave 作为新 Master

• 配置中心：客户端通过连接哨兵来获得当前 Redis 服务的主节点

3. 配置

3 个哨兵：自动监控和维护集群，不存放数据

1 主 2 从：用于数据读取和存放

3.1 重点参数说明

sentinel monitor中的quorum代表确认客观下线的最少的哨兵数量

至少有quorum 个节点认为这个 master 有故障才会对 master 进行下线以及故障转移

# 1.设置要监控的master服务器 (重点)
sentinel monitor <master-name> <ip><redis-port> <quorum>

# 2.连接master的密码 (重点)
sentinel auth-pass <master-name> <password>

# 3.指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线
sentinel down-after-milliseconds <master-name> <milliseconds>：

# 4. 表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据
sentinel parallel-syncs <master-name> <nums>：

# 5.故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败
sentinel failover-timeout <master-name> <milliseconds>：

# 6.配置当某一事件发生时所需要执行的脚本
sentinel notification-script <master-name> <script-path> ：

# 7.客户端重新配置主节点参数脚本
sentinel client-reconfig-script <master-name> <script-path>：

3.2 哨兵启动命令

redis-sentinel /etc/redis/sentinel.conf

另外 redis 哨兵启动的默认端口是 26379

3.3 sentinel 配置

复制三份，修改端口

protected-mode no
port 26380
logfile "/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111

3.4 docker-compose.yaml 文件

version: "3"
services:
  redis_sentinel1:
    image: redis:latest
    volumes:
      - ./sentinel1/conf:/etc/redis
      # - ./sentinel1/conf/sentinel.conf:/etc/redis/sentinel.conf
      - ./sentinel1/data/:/tmp
    container_name: redis-sentinel-1
    command: redis-sentinel /etc/redis/sentinel.conf
    ports:
      - "26380:26380"
    # 如果配置在一个yaml文件中需要指定depends-on,启动该服务项启动redis主从机
    network_mode: "bridge"
  redis_sentinel2:
    image: redis:latest
    volumes:
      # - ./sentinel2/conf/sentinel.conf:/etc/redis/sentinel.conf
      - ./sentinel2/conf:/etc/redis
      - ./sentinel2/data/:/tmp
    container_name: redis-sentinel-2
    command: redis-sentinel /etc/redis/sentinel.conf
    ports:
      - "26381:26381"
    # 如果配置在一个yaml文件中需要指定depends-on,启动该服务项启动redis主从机
    network_mode: "bridge"
  redis_sentinel3:
    image: redis:latest
    volumes:
      - ./sentinel3/conf:/etc/redis
      # - ./sentinel3/conf/sentinel.conf:/etc/redis/sentinel.conf
      - ./sentinel3/data/:/tmp
    container_name: redis-sentinel-3
    command: redis-sentinel /etc/redis/sentinel.conf
    ports:
      - "26382:26382"
    # 如果配置在一个yaml文件中需要指定depends-on,启动该服务项启动redis主从机
    network_mode: "bridge"

4. 验证

1. 手动关闭 master

2. 重新连接从机 redis

127.0.0.1:6382> info replication
# Replication
role:slave
master_host:172.17.0.4
master_port:6381
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_read_repl_offset:652074
slave_repl_offset:652074
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:19ae457843952094ba996218481274bc712ea5b5
master_replid2:82fa1f996e877547f7c96ca58b8ca3bf76117deb
master_repl_offset:652074
second_repl_offset:497065
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_off

可以看到主节点变为了 6381

之前的 master 节点重新连接回来之后，会变为 salve

5. 常见问题

5.1 哨兵日志报错

WARNING: Sentinel was not able to save the new configuration on disk!!!: Device or resource busy.

解决方法: docker compose 映射数据卷里面映射目录

volumes:
  - ./sentinel1/conf:/etc/redis
  # - ./sentinel1/conf/sentinel.conf:/etc/redis/sentinel.conf

5.2 新 master 选举结束后 , 需要重新连接 redis

broken pipet 的意思是对端的管道已经断开，往往发生在远端把这个读 / 写管道关闭了，无法往管道里面写数据

5.3 文件的 conf，会被哨兵动态的进行修改

Master-Slave 切换后，master_.redis.conf slave_redis..conf和sentinel.conf的内容都会发生改变，即master_.redis..conf中会多一行 slaveof 的配置，sentinel.conf 的监控目标会随之调换

6. 哨兵运行流程和选举原理

6.1 哨兵选举 leader

1. 三个哨兵监控一主二从运行中，正常运行中，突然 maste 主机挂了

2. 哨兵检测到了 master 的状态为主观下线（SDOWN），从 sentinel 的角度老看，如果发送了ping 心跳后，在一定时间内没有收到合法的回复，就达到了 SDOWN 的条件

   1. 配置文件的down-afte-milliseconds 设置了判断主管下线的时间，默认为30秒

3. ODWN（客观下线）：需要一定数量的 sentinel，多个哨兵达成一致意见才能认为一个 master 客观上以及宕机

4. 从哨兵中选举出 leader ，由该 leader 执行 failver （故障迁移）

   1. leader 是通过 raft 算法选举得出的

这里就是选举出 leader

6.4 lender 选举出新的 master

• master 选举规则

1. 首先会比较 slave 的配置文件中读取replica-priority ( 数字越小 , 权限越高 )，如果相同就进行下一个offset 偏移量

2. 偏移量最大的节点会被选为 master

3. 最小 Run ID 的从节点（字典顺序，ASCII 码）

• 选举完成后续工作

1. leafer 会对新 master 执行 slaveof no one 命令让选出来的节点成为新的主节点，并通过 slaveof 命令让其他节点成为其从节点

2. leader 向其他 leader 向其他 slave 发送命令，让剩余的 slave 成为新的 master 节点的 slave

7. 哨兵的使用建议

1. 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用

2. 哨兵节点的数量应该是奇数

3. 各个哨兵节点的配置应一致

4. 如果哨兵节点部署在 Docker 等容器里面，尤其要注意端口的正确映射

5. 哨兵集群+主从复制，并不能保证数据零丢失，所以需要集群