Redis——Redis 哨兵模式
Redis 哨兵模式
- 哨兵模式的简介
- 哨兵的作用
- 启用哨兵模式
- 配置哨兵
- 启动哨兵
- 哨兵模式的工作原理
- 阶段一:监控阶段
- 阶段二:通知阶段
- 阶段三:故障转移阶段
- 发现故障
- 选出领头sentinel
- 挑选备选master
- 主从切换总结
哨兵模式的简介
- 主从切换技术的方法是︰当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。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
- 当第一个哨兵启动之后,先连接master,发送
info
指令 - 哨兵和master建立了一个cmd连接,专门用于发送数据。
在这个过程中,还保存了所有主从哨兵信息 - 在master端,也记录保存了主从哨兵信息
- 哨兵根据获取到的slave信息,去连接每一个slave,发送
info
指令 - 下一个哨兵进入之后,也是第一个连接master,但是它发现之前保存的信息,并建立cmd连接,保存了master,slaves,sentinels信息(哨兵信息中包含之前第一个进来的哨兵信息)
- 为了保证两台哨兵信息同步,哨兵之间又建立了连接,发布订阅,可以相互对称信息,并且互相发送
ping
命令 - 当第三个哨兵进来之后,进行相同操作,然后和另外两个哨兵组成一个循环的网络,通过订阅互相共享信息。这样获取信息速度快
阶段二:通知阶段
通知阶段是一个信息长期维护的阶段
- 三个哨兵组成一个小的群体,进行信息的共享互通
- 哨兵通过建立的cmd连接,获取master和slave的对应的工作状态
- 不管哪个哨兵获取到信息,就会在群体之间互通,sentinel发布的信息就是一个
hello
的信息,查看主从能否回复 - 其他sentinel都可以收到回复
阶段三:故障转移阶段
发现故障
- 当sentinel向master发送指令,结果master没有回复,发到一定阶段以后,sentinel主观认为master掉线,因此会给master标记一个
flags:SRI_S_DOWN
(主观下线) - 然后sentinel会把master掉线的信息传给哨兵内网里,发送一条指令指名master挂了,同网内的其他sentinel接到这个指令后就会,一直给master发送指令,结果发现master果然不回复。确定master的确掉线。然后标记
flags:SRI_O_DOWN
(客观下线) - 只要超过半数以上的sentinel认为master挂了,则标记
flags:SRI_O_DOWN
选出领头sentinel
- 所有sentinel在一个网络中,每个sentinel都会相当领头的
- 然后每个sentinel会发送一个信息,包含:挂掉master的ip、端口,和之前竞选的次数,自己的runid
- 所有sentinel开始投票,每个sentinel可以投一票,sentinel按照获得信息的先后顺序,将票数投给它一个收到信息的sentinel
循环投票后票数最高的sentinel被选作领头去选择新的master
监控
- 同步信息
通知
- 保持联通
故障转移
- 发现问题
- 竞选负责人
- 优选新master
- 新master上任,其他slave切换master,原master作为slave故障回复后连接
挑选备选master
- 挑选在线的
- 挑选响应速度快的
- 与原master断开时间最近的
优先原则
- 优先级
- offset
- runid
发送指令(sentinel)
- 向新的master发送slaveof no one
- 向其他slave发送slaveof 新的masterIP、端口
主从切换总结
服务器列表中挑选备选master
- 在线的
- 响应慢的
- 与原master断开时间久的
优先原则
- 优先级
- offset
- runid
重启旧的master之后,作为从机
还没有评论,来说两句吧...