Redis sentinel 来龙去脉 简单说明

此篇的前置原理为,需要能安装REDIS 服务器,并且配置主从关系, Redis 有两种高可用, redis cluster 和 redis sentinel , 今天要说的是redis 的 sentinel, redis sentinel 是从redis 2.8开始提供的一个redis 高可用的功能,这里有几个问题

有人提出redis 是缓存式的数据库,为什么还要高可用,直接重新启动,利用本身的日志进行恢复即可, 实际上这主要与redis所使用的场景有关,例如在架构设计中,redis 属于与应用关联性紧密的设计, 这样的设计让系统在高并发和高密度的访问中游刃有余,并且也是传统数据库和应用系统高并发中的一层缓冲,不少系统中设计的redis 是非常重要的,如果redis停止工作,则整体的应用就处于停摆的状态,所以即使redis 可以快速重启,读入相关日志,恢复到故障前的状态,但有些应用设计为低容忍, 则为了保证业务redis 必然要设计成高可用的状态.

首先安装redis 配置好主从, 这里已两个节点为例, redis 1 , redis 2 为例,

redis 1

bind 0.0.0.0

port 6379

timeout 10

daemonize yes

loglevel notice

logfile "/redis_data/errorlog.log"

save 900 1

save 300 10

save 60 10000

dbfilename "dump.rdb"

dir "/redis_data"

masterauth "password"

replica-priority 100

requirepass "password"

maxmemory xxxxxxxkb

appendonly yes

appendfilename "appendonly.aof"

appendfsync everysec

redis2

bind 0.0.0.0

port 6379

timeout 10

daemonize yes

loglevel notice

logfile "/redis_data/errorlog.log"

save 900 1

save 300 10

save 60 10000

dbfilename "dump.rdb"

dir "/redis_data"

masterauth "password"

replica-priority 100

requirepass "password"

maxmemory xxxxxxxkb

appendonly yes

appendfilename "appendonly.aof"

appendfsync everysec

slaveof 192.168.198.100 6379

配置完成这里就不在赘述,个体安装redis数据库的问题了,.

redis sentinel 节点本身安装灵活,实际上不非要安装在redis 数据库本身的节点中,但大部分的习惯还是安装在和redis的数据库服务器中, Redis sentinel 本身是一个分布式架构, 其中包含若干个sentinel节点和 redis 节点, 对于高可用来讲, redis 的sentinel 应该至少为 3 节点, 这也符合大多数原理, 但实际当中部分的redis sentinel 部署是两个节点. 每个sentinel 节点对数据节点和其他的sentinel 节点进行监控. 当有节点失控后,sentinel会被触发并和其他的sentinel节点协商来决定,并开始故障转移,整个过程是完全自动的.

总结 sentinel 节点的功能

1定期监控sentinel节点定期检测redis 数据节点,以及其他的sentinel节点

2 sentinel会将节点故障转移的结果通知给应用

3 故障转移从节点晋升为主节点的工作也需要sentinel来进行设置.

下面是配置文件

port 26379

sentinel 访问的端口号

daemonize yes

释放在后端运行

pidfile "/var/run/redis-sentinel.pid"

logfile "/redis_data/sential.log"

日志文件存放地

dir "/redis_data"

sentienl 数据目录

sentinel monitor redis1 192.168.198.100 6379 1

sentinel 监控的主机地址,以及端口号,和几个sentinel 节点来判断redis主机失效是否切换.

sentinel down-after-milliseconds redis1 5000

多长时间无法连接到redis primary server 就开始准备切换

sentinel parallel-syncs redis 1

在有多副本的情况下,在主机切换后,有多少副本指向新的主

sentinel auth-pass redis1 1234.com

sentinel 之前进行认证的密码

requirepass 1234.com

sentinel 和 redis之间访问的密码

sentinel 有两种部署方式

1 针对多组redis 来说,部署三个节点的 sentinel 即可, 可以通过三个一组的sentinel 节点来管理 多组 redis 主从复制

2 针对少量的redis 主从复制,将 sentinel 和 redis 部署在同一台服务器

在已经运行的redis节点,运行sentinel 后, 日志图

实际上sentinel 在启动后,本身的sentinel.conf 就会被改变,以上的信息是在启动sentinel服务后,由sentinel 添加到 sentinel.conf 的文件中

sentinel 在迁移中的一些过程

下面是sentinel.c 的开头, 其中传给sentinel 的参数

其中定义了传入参数中,如何标记当前节点的信息,传入的二进制数中,

第一位 机器是否是master

第二位 机器释放是slave

第三位 机器是否是sentinel

第四位 机器是否是主观down

第五位 机器释放是客观down

第六位 sentinel 确认master down

第七位 failover 正在进行中

第八位 选择哪个slave为主

第九位 哪个新master发送slaveof 给其他从

第十位 从同步的进度

第十一位 新主的与从同步

第十二位 master 新主生效

第十三位 SCRIPT KILL already sent on -BUSY

在sentinal 中以后两个关于redis 服务器的状态的问题

SDOWN: subjectively down 主观失效, 既当前的sentinel 对于redis服务器的状态已经至为不可用的状态. 而 ODOWN: objectively down 的意思为多数(至少不是一个)sentinel 认为此节点的redis 已经失效.

当sentinel 产生了 objectively down 后就要进行failover的操作了.

那么SDOWN 的状态是从哪里来的, 在REDIS 中主从服务器会建立TCP连接,并周期性的发送ping,默认为1秒钟的时间.在 down-after-milliseconds 时间内如果彼此之间有无法响应的情况,则会启用 sdown, 如果sdown 为主服务器,此时判断出主DOWN的sentinel 会开始发送 is-master-down-by-addr 信息,当达到大多数sentinel 都确认后,就会产生ODOWN, 启动FAILOVER操作

首先sentinel之间是怎么进行互相沟通的

1 每个sentinel 在配置中都表明首次与REIDS 主进行沟通

2 每个sentinel都会发送自己的 hello 信息, 发送自己的ip 和 port

3 通过redis primary 这个介质, sentinel 之间进行了沟通

4 借由 redis primary 与 SLAVE 之间的信息沟通,redis primary 也获得了SLAVE的信息, sentinel 也就通过redis primary 获得slave的信息,并开始进行沟通.

sentinel初始配置

port 26379

pidfile "/redis_data/sentinel.pid"

dir "/redis_data"

daemonize yes

protected-mode no

logfile "/redis_data/sentinel.log"

sentinel myid 2a9dca6062c5bc4d8811c614970c6aa1d38472b5

sentinel deny-scripts-reconfig yes

sentinel monitor redisMaster 192.168.198.101 6379 2

sentinel down-after-milliseconds redisMaster 1000

sentinel failover-timeout redisMaster 6000

sentinel client-reconfig-script redisMaster /redis_data/vip.sh

requirepass "1234.com"

# Generated by CONFIG REWRITE

maxclients 4064

运行后sentinel 添加的信息

sentinel auth-pass redisMaster 1234.com

sentinel config-epoch redisMaster 7

sentinel leader-epoch redisMaster 7

sentinel known-replica redisMaster 192.168.198.100 6379

sentinel known-replica redisMaster 192.168.198.102 6379

sentinel known-sentinel redisMaster 192.168.198.102 26379 711a3d1d1e216abc13c275de972f15307c4a7c30

sentinel known-sentinel redisMaster 192.168.198.101 26379 f698f72600e34df22b878a57a4583fa98200b1d9

sentinel current-epoch 7

IP 切换的脚本

#!/bin/bash

MASTER_IP=${6}

MY_IP='192.168.198.101' # 每个Server本身的IP

VIP='192.168.198.106' # VIP

NETMASK='24' # Netmask

INTERFACE='ens33' # 接口

if [ {MASTER_IP} = {MY_IP} ]; then

sudo /sbin/ip addr add {VIP}/{NETMASK} dev

sudo /sbin/arping -q -c 3 -A {VIP} -I {INTERFACE}

exit 0

else

sudo /sbin/ip addr del {VIP}/{NETMASK} dev

exit 0

fi

exit 1

大部分出问题的地方主要在切换的脚本

MASTER_IP=${6}, 下图是配置文件的具体解释, 在执行脚本时会传递几个参数

1 master-name

2 role

3 state

4 from-ip

5 from-port

6 to-ip

7 to-port

那这里就有问题了,在执行reconfig.sh 时是所有的sentinel 都执行吗?

如果都执行执行几遍.

实际上这个问题并不一定要去看源代码,直接在reconfig 脚本中部署打印的语句到日志中, 类似我们调试某些存储过程的方式.

最后以我上面的配置, 在除primary节点上 reconfig 脚本执行了三次.

另外如何测试的问题, 当然可以通过命令来关闭REIDS , 但其实也有更好的方式来测试系统是否配置成功可以进行切换,

DEBUG sleep 秒 的方式可以让主的redis 在你设置的时间无响应而触发你切换.