redis 之redis-sentinel主从复制高可用

.redis主从复制背景问题

Redis主从复制可将主节点数据同步给从节点,从节点此时有两个作用:

(1)一旦主节点宕机,从节点作为主节点的备份可以随时顶上来。

(2)扩展主节点的读能力,分担主节点读压力。

但是问题是:

一旦主节点宕机,从节点上位,那么需要人为修改所有应用方的主节点地址(改为新的master地址),还需要命令所有从节点复制新的主节点

那么这个问题,redis-sentinel就可以解决了

. Redis-Sentinel

Redis-Sentinelredis官方推荐的高可用性解决方案,

当用redismaster-slave的高可用时,如果master本身宕机,redis本身或者客户端都没有实现主从切换的功能。

redis-sentinel就是一个独立运行的进程,用于监控多个master-slave主从复制,

自动发现master宕机,进行自动切换slave > master

sentinel主要功能如下:

不时的监控redis是否良好运行,如果节点不可达就会对节点进行下线标识

如果被标识的是主节点,sentinel就会和其他的sentinel节点协商,如果其他节点也人为主节点不可达,就会选举一个sentinel节点来完成自动故障转义

master-slave进行切换后,master_redis.confslave_redis.confsentinel.conf的内容都会发生改变,即master_redis.conf中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换

.Sentinel的工作方式

每个Sentinel以每秒钟一次的频率向它所知的MasterSlave以及其他 Sentinel 实例发送一个 PING 命令

如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 Sentinel 标记为主观下线。

如果一个Master被标记为主观下线,则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。

 

当有足够数量的 Sentinel(大于等于配置文件指定的值)在指定的时间范围内确认Master的确进入了主观下线状态, 则Master会被标记为客观下线

在一般情况下, 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有MasterSlave发送 INFO 命令

MasterSentinel 标记为客观下线时,Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次

若没有足够数量的 Sentinel 同意 Master 已经下线, Master 的客观下线状态就会被移除。

Master 重新向 Sentinel PING 命令返回有效回复, Master 的主观下线状态就会被移除。

 

主观下线和客观下线

主观下线:Subjectively Down,简称 SDOWN,指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。

客观下线:Objectively Down, 简称 ODOWN,指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断,并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后,得出的Master Server下线判断,然后开启failover.

SDOWN适合于MasterSlave,只要一个 Sentinel 发现Master进入了ODOWN, 这个 Sentinel 就可能会被其他 Sentinel 推选出, 并对下线的主服务器执行自动故障迁移操作。

ODOWN只适用于Master,对于SlaveRedis 实例,Sentinel 在将它们判断为下线前不需要进行协商, 所以SlaveSentinel 永远不会达到ODOWN

.Redis Sentinel架构

redis的一个进程,但是不存储数据,只是监控redis

sentinel 会通过命令连接向被监视的主从服务器发送 “hello”信息,该信息包含sentinelip,端口号,id等内容,以此来向其他sentinel宣告自己的存在。与此同时sentinel会通过订阅连接接收其他sentinel”hello”信息,以此来发现监视同一个主服务器的其他sentinel

 

 

 

从图中sentinel1 通过发送hello信息来让sentinel2sentinel3发现自己,其他两个sentinel也会进行类似的操作。

 

 

 

redis主库服务故障,主从复制重新判断主从结构的过程

 

 

1.redis命令整理

 

官网地址:http://redisdoc.com/

redis-cli info #查看redis数据库信息

redis-cli info replication #查看redis的复制授权信息

redis-cli info sentinel   #查看redis的哨兵信息

2.配置哨兵模式redis sentinel实现主从复制及自动切换过程

配置redis数据库, 一主

环境:

192.168.1.209  配置了12

192.168.1.209  配置了2

(注意由于虚拟机上配置,虚拟机有限,所以将一台服务配置多个从库,生产从不会是这样的,生产中都是一个库一台服务器的)

(1)主从库配置文件如下

192.168.1.209 主库

# 声明端口
port 6379
# 表示后台启动
daemonize yes
# 将pid文件放到某目录下
pidfile /data/6379/redis.pid
# 日志级别和日志目录
loglevel notice
logfile "/data/6379/redis.log"
# 持久化相关
# dir /data/6379
# 安全模式
protected-mode no
# 密码设置,redis一般不要密码
# requirepass hsz

192.168.1.209 从库1   6380端口

# 声明端口
port 6380
# 表示后台启动
daemonize yes
# 将pid文件放到某目录下
pidfile /data/6380/redis.pid
# 日志级别和日志目录
loglevel notice
logfile "/data/6380/redis.log"
# 持久化相关
# dir /data/6380
# 安全模式
protected-mode no
# 密码设置,redis一般不要密码
# requirepass hsz

slaveof 192.168.1.209 6379

192.168.1.209 从库2 6381 端口

# 声明端口
port 6381
# 表示后台启动
daemonize yes
# 将pid文件放到某目录下
pidfile /data/6381/redis.pid
# 日志级别和日志目录
loglevel notice
logfile "/data/6381/redis.log"
# 持久化相关
# dir /data/6380
# 安全模式,如果开启文件不会被修改
protected-mode no
# 密码设置,redis一般不要密码
# requirepass hsz

dir /data/6381/
dbfilename  dbmp.rdb
save  900 1
save 300 10
save 60  10000
slaveof 192.168.1.209 6379

192.168.1.208 从库1 6381端口

port 6381
daemonize yes
pidfile /data/6381/redis.pid
loglevel notice
logfile "/data/6381/redis.log"
dbfilename dump.rdb
dir /data/6381
protected-mode no
# 主库ip和端
slaveof 192.168.1.209 6379

192.168.1.208 从库1 6382端口

port 6382
daemonize yes
pidfile /data/6382/redis.pid
loglevel notice
logfile "/data/6382/redis.log"
dbfilename dump.rdb
dir /data/6382
protected-mode no
# 主库ip和端口
slaveof 192.168.1.209 6379

做好配置文件后都进行redis启动

redis-server redis配置文件名

最后确定主从信息及关系:

(2)配置个哨兵

在配置之前首先进行学习下,配置哨兵的配置文件的各项解析:

# Sentinel节点的端口

port 26379  

dir /var/redis/data/

logfile "26379.log"

# sentinel announce-ip 127.0.0.1   # 宣告哨兵IP, 此配置只有当使用非127.0.0.1的IP配置哨兵无法成功时加上,同时redis三个服务端也需要同步修改IP

# 当前Sentinel节点监控 127.0.0.1:6379 这个主节点

# 2代表判断主节点失败至少需要2个Sentinel节点节点同意

# mymaster是主节点的别名

sentinel monitor mymaster 127.0.0.1 6379 2

# 每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达,如果超过30000毫秒30s且没有回复,则判定不可达

sentinel down-after-milliseconds mymaster 30000

# 当Sentinel节点集合对主节点故障判定达成一致时,Sentinel领导者节点会做故障转移操作,选出新的主节点,原来的从节点会向新的主节点发起复制操作,限制每次向新的主节点发起复制操作的从节点个数为1

sentinel parallel-syncs mymaster 1

# 故障转移超时时间为180000毫秒

sentinel failover-timeout mymaster 180000

daemonize yes

关于哨兵的配置,将5个哨兵配置到两台上,一台3个一台2

那么接下来哨兵1配置(由于和主机同一台所以配置127.0.0.1):

# vim redis-sentinel-26379.conf

port 26379

dir /var/redis/data/

logfile "26379.log"

sentinel monitor mymaster 192.168.1.209 6379 2

sentinel down-after-milliseconds mymaster 30000

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

daemonize yes

启动之前新建日志目录

#mkdir -p /var/redis/data/

使用以下命令启动redis-sentinel

# redis-sentinel redis-sentinel-26379.conf

然后进行查看通信状态:# redis-cli -p 26379 info sentinel

可以从信息看出,有一台主库,ip及端口,4台从库,和1个哨兵,因为才配置一个,所有哨兵为

哨兵2配置:

# vim redis-sentinel-26380.conf

port 26380

dir /var/redis/data/

logfile "26380.log"

sentinel monitor mymaster 192.168.1.209 6379 2

sentinel down-after-milliseconds mymaster 30000

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

daemonize yes

启动之前新建日志目录

# mkdir -p /var/redis/data/

使用以下命令启动redis-sentinel

# redis-sentinel redis-sentinel-26380.conf

然后进行查看通信状态:# redis-cli -p 26380 info sentinel

哨兵3配置

# vim redis-sentinel-26380.conf

port 26380

dir /var/redis/data/

logfile "26380.log"

sentinel monitor mymaster 192.168.1.209 6379 2

sentinel down-after-milliseconds mymaster 30000

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

daemonize yes

启动之前新建日志目录

# mkdir -p /var/redis/data/

使用以下命令启动redis-sentinel

# redis-sentinel redis-sentinel-26380.conf

然后进行查看通信状态:# redis-cli -p 26380 info sentinel

哨兵4配置

# vim redis-sentinel-26381.conf

port 26381

dir /var/redis/data/

logfile "26381.log"

sentinel monitor mymaster 192.168.1.209 6379 2

sentinel down-after-milliseconds mymaster 30000

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

daemonize yes

启动之前新建日志目录

# mkdir -p /var/redis/data/

使用以下命令启动redis-sentinel

# redis-sentinel redis-sentinel-26381.conf

然后进行查看通信状态:# redis-cli -p 26381 info sentinel

哨兵5配置

# vim redis-sentinel-26382.conf

port 26382

dir /var/redis/data/

logfile "26382.log"

sentinel monitor mymaster 192.168.1.209 6379 2

sentinel down-after-milliseconds mymaster 30000

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

daemonize yes

启动之前新建日志目录

# mkdir -p /var/redis/data/

使用以下命令启动redis-sentinel

# redis-sentinel redis-sentinel-26382.conf

然后进行查看通信状态:# redis-cli -p 26382 info sentinel

最后可以查看下哨兵的配置文件,会自动加上这些内容:

 

而从库的配置文件会修改为这一句配置:

 

(3)进行redis高可用故障实验

关闭主库进程(模拟生产中服务器挂掉)如下截图:

此时进行等待30秒。。。。

从其中一个哨兵进行查看

查看可知:新的主库为192.168.1.209:6381

# redis-cli -p 6381 info replication

到这个redis主库进行查看信息,并查看数据,可知从库可同步数据:

最后高可用实现

 

posted @ 2018-07-20 22:55  pycoder_hsz  阅读(230)  评论(0编辑  收藏  举报