Redis 哨兵模式

哨兵模式的简介

  • 主从切换技术的方法是︰当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel (哨兵）架构来解决这个问题。

  • 哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。

哨兵的作用

  • 监控
    • 不断的检查master和slave是否正常运行。
    • master存活检测、master与slave运行情况检测
  • 通知（提醒）
    • 当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知。
  • 自动故障转移
    • 断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址

注意：

  • 哨兵也是一台redis服务器，只是不提供数据服务
  • 通常哨兵配置数量为单数

启用哨兵模式

配置哨兵

  • 配置一主二从结构

  • 配置三个哨兵（配置相同，端口不同）
    配置sentinel.conf

  • 启动哨兵

    redis-sentinel sentinel-端口号.conf

查看哨兵配置文件
[root@maomao redis-6.2.1]# cat sentinel.conf | grep -v '^#' |grep -v '^$'
port 26379
daemonize no
pidfile /var/run/redis-sentinel.pid
logfile ""
dir /tmp
sentinel monitor mymaster 127.0.0.1 6379 2		# 自定义哨兵集群名字 最后一个2意思是 如果有两个哨兵判断master宕机 就真的宕机 
sentinel down-after-milliseconds mymaster 30000		# master连接了多少时间没有响应，则判断宕机 30000毫秒
acllog-max-len 128
sentinel parallel-syncs mymaster 1		# 当之前的master挂机之后 ，有新的master上位，一次有多少个master同步，根据性能
sentinel failover-timeout mymaster 180000	# 进行同步的时候多长时间同步完成算有效，多长时间同步超时
sentinel deny-scripts-reconfig yes
SENTINEL resolve-hostnames no
SENTINEL announce-hostnames no

然后将哨兵配置文件拷贝到redis配置文件那里
cat sentinel.conf | grep -v '^#' |grep -v '^$' > /usr/local/bin/redis_config/sentinel-26379.conf

然后修改配置
port 26379
daemonize no
pidfile /var/run/redis-sentinel.pid
logfile ""
dir /usr/lcoal/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
acllog-max-len 128
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
SENTINEL resolve-hostnames no
SENTINEL announce-hostnames no

修改另外两个哨兵的配置
sed 's/26379/26380/g' sentinel-26379.conf >sentinel-26380.conf 
sed 's/26379/26381/g' sentinel-26379.conf >sentinel-26381.conf 

清空之前的数据
[root@maomao data]# ll
total 476
-rw-r--r-- 1 root root 465174 Apr 18 09:22 6379.log
-rw-r--r-- 1 root root   4645 Apr 18 03:50 6380.log
-rw-r--r-- 1 root root   3833 Apr 18 09:38 appendonly-6379.aof
-rw-r--r-- 1 root root    391 Apr 18 22:25 dump-6379.rdb
-rw-r--r-- 1 root root    391 Apr 18 22:25 dump.rdb
[root@maomao data]# rm -rf *

补充：哨兵模式的全部配置

# Example sentinel.conf

# 哨兵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 mymaster 127.0.0.1 6379 2

# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd


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

# 这个配置项指定了在发生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

# 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	# 一般都是由运维来配置

启动哨兵

先起主机，然后从机，最后哨兵

redis-sentinel redis_config/sentinel-26379.conf 

连接哨兵客户端
redis-cli -p 26379

当哨兵启动之后 哨兵的配置文件也会发生变化
在配置最后会自动添加从机信息
sentinel known-replica mymaster 127.0.0.1 6381
sentinel known-replica mymaster 127.0.0.1 6380

启动第二，三台哨兵
redis-sentinel redis_config/sentinel-26380.conf
redis-sentinel redis_config/sentinel-26380.conf

配置文件又添加了哨兵的信息
sentinel known-replica mymaster 127.0.0.1 6381
sentinel known-replica mymaster 127.0.0.1 6380
sentinel known-sentinel mymaster 127.0.0.1 26381 446d48f0913658b1cc89d5a9ea181864e63a5086
sentinel known-sentinel mymaster 127.0.0.1 26380 04d12b0c3b213a7e6b64a2ce71e5beb532a79324

验证主从是否正常
127.0.0.1:6379> set name maomao
OK

127.0.0.1:6380> get name
"maomao"

验证哨兵的功能
把master停掉
1903:X 18 Apr 2021 22:48:56.604 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
1903:X 18 Apr 2021 22:48:56.605 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
1903:X 18 Apr 2021 22:48:57.084 * +sentinel sentinel 4423fe6bdf4b9a76dc44149cb4c324f06d5a845c 127.0.0.1 26379 @ mymaster 127.
0.0.1 63791903:X 18 Apr 2021 22:48:57.305 * +sentinel sentinel 04d12b0c3b213a7e6b64a2ce71e5beb532a79324 127.0.0.1 26380 @ mymaster 127.
0.0.1 63791903:X 18 Apr 2021 22:52:00.711 # +sdown master mymaster 127.0.0.1 6379
1903:X 18 Apr 2021 22:52:00.777 # +new-epoch 1
1903:X 18 Apr 2021 22:52:00.778 # +vote-for-leader 4423fe6bdf4b9a76dc44149cb4c324f06d5a845c 1
1903:X 18 Apr 2021 22:52:00.801 # +odown master mymaster 127.0.0.1 6379 #quorum 3/2
1903:X 18 Apr 2021 22:52:00.801 # Next failover delay: I will not start a failover before Sun Apr 18 22:58:01 2021
1903:X 18 Apr 2021 22:52:01.454 # +config-update-from sentinel 4423fe6bdf4b9a76dc44149cb4c324f06d5a845c 127.0.0.1 26379 @ mym
aster 127.0.0.1 63791903:X 18 Apr 2021 22:52:01.454 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380
1903:X 18 Apr 2021 22:52:01.454 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380
1903:X 18 Apr 2021 22:52:01.454 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380
1903:X 18 Apr 2021 22:52:31.484 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380

6379停掉 主机从6379变成了6380

6380可以写数据
127.0.0.1:6380> set niu niu
OK

哨兵模式的工作原理

  • 哨兵在进行主从切换过程中经历三个阶段
    • 监控
    • 通知
    • 故障转移

阶段一：监控阶段

  • 用于同步各个节点的状态信息
    • 获取各个sentinel的状态（是否在线）
    • 获取master的状态
      • master属性
        • runid
        • role：master
      • 各个slave的详细信息
    • 获取所有slave的状态（根据master中的slave信息）
      • slave属性
        • runid
        • role：slave
        • master_host、master_port
        • offset

在这里插入图片描述

  1. 当第一个哨兵启动之后，先连接master，发送info指令
  2. 哨兵和master建立了一个cmd连接，专门用于发送数据。
    在这个过程中，还保存了所有主从哨兵信息
  3. 在master端，也记录保存了主从哨兵信息
  4. 哨兵根据获取到的slave信息，去连接每一个slave，发送info指令
  5. 下一个哨兵进入之后，也是第一个连接master，但是它发现之前保存的信息，并建立cmd连接，保存了master，slaves，sentinels信息（哨兵信息中包含之前第一个进来的哨兵信息）
  6. 为了保证两台哨兵信息同步，哨兵之间又建立了连接，发布订阅，可以相互对称信息，并且互相发送ping命令
  7. 当第三个哨兵进来之后，进行相同操作，然后和另外两个哨兵组成一个循环的网络，通过订阅互相共享信息。这样获取信息速度快

阶段二：通知阶段

在这里插入图片描述
通知阶段是一个信息长期维护的阶段

  1. 三个哨兵组成一个小的群体，进行信息的共享互通
  2. 哨兵通过建立的cmd连接，获取master和slave的对应的工作状态
  3. 不管哪个哨兵获取到信息，就会在群体之间互通，sentinel发布的信息就是一个hello的信息，查看主从能否回复
  4. 其他sentinel都可以收到回复

阶段三：故障转移阶段

发现故障

在这里插入图片描述

  1. 当sentinel向master发送指令，结果master没有回复，发到一定阶段以后，sentinel主观认为master掉线，因此会给master标记一个flags：SRI_S_DOWN（主观下线）
  2. 然后sentinel会把master掉线的信息传给哨兵内网里，发送一条指令指名master挂了，同网内的其他sentinel接到这个指令后就会，一直给master发送指令，结果发现master果然不回复。确定master的确掉线。然后标记flags：SRI_O_DOWN（客观下线）
  3. 只要超过半数以上的sentinel认为master挂了，则标记flags：SRI_O_DOWN

选出领头sentinel

在这里插入图片描述

  1. 所有sentinel在一个网络中，每个sentinel都会相当领头的
  2. 然后每个sentinel会发送一个信息，包含：挂掉master的ip、端口，和之前竞选的次数，自己的runid
  3. 所有sentinel开始投票，每个sentinel可以投一票，sentinel按照获得信息的先后顺序，将票数投给它一个收到信息的sentinel
  4. 循环投票后票数最高的sentinel被选作领头去选择新的master
  • 监控
    • 同步信息
  • 通知
    • 保持联通
  • 故障转移
    • 发现问题
    • 竞选负责人
    • 优选新master
    • 新master上任，其他slave切换master，原master作为slave故障回复后连接

挑选备选master

  1. 挑选在线的
  2. 挑选响应速度快的
  3. 与原master断开时间最近的
  4. 优先原则
    • 优先级
    • offset
    • runid
  5. 发送指令（sentinel）
    • 向新的master发送slaveof no one
    • 向其他slave发送slaveof 新的masterIP、端口

主从切换总结

  • 服务器列表中挑选备选master
    • 在线的
    • 响应慢的
    • 与原master断开时间久的
    • 优先原则
      • 优先级
      • offset
      • runid

重启旧的master之后，作为从机

# redis # 数据库 # linux
Logo
华为云开发者联盟

为开发者提供学习成长、分享交流、生态实践、资源工具等服务，帮助开发者快速成长。

更多推荐

cover

【GaussDB(for MySQL)】 Big IN查询优化

avatar 华为云开发者联盟
cover

GaussDB细粒度资源管控技术透视

avatar 华为云开发者联盟
cover

关于Java Chassis 3的契约优先（API First）开发

avatar 华为云开发者联盟