资讯专栏INFORMATION COLUMN

使用Sentinel配置Redis 3.x主从高可用服务

Enlightenment / 3214人阅读

摘要:若重新向的命令返回有效回复,的主观下线状态就会被移除。主观下线和客观下线主观下线,简称,指的是当前实例对某个服务器做出的下线判断。单位为毫秒,判定为主观下线第七行指定在执行故障转移时,最多可以有多少个同时对新的进行同步。

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案,当用Redis做Master-slave的高可用方案时,假如master宕机了,Redis本身(包括它的很多客户端)都没有实现自动进行主备切换,而Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后能进行自动切换。

它的主要功能有以下几点

不时地监控redis是否按照预期良好地运行;
如果发现某个redis节点运行出现状况,能够通知另外一个进程(例如它的客户端);
能够进行自动切换。当一个master节点不可用时,能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址

1.集群规划
172.16.1.42 6379 Master

172.16.1.43 6379 Slave1

172.16.1.43 6380 Slave2

2.集群配置

2.1 安装reids

# yum install gcc gcc-c++ tcl
# cd /opt/redis/
# tar xvf redis-3.2.8.tar.gz
# cd redis-3.2.8
# make install
# make test
# cd utils/

# 初始化数据
# ./install_server.sh

2.2 配置并启动redis
Master:

# vim master.conf
port 6379
bind 0.0.0.0
masterauth 123456
requirepass 123456
slave-read-only yes

#启动
# redis-server /etc/redis/master.conf

Slave1:

# vim slave1.conf

port 6379
bind 0.0.0.0
slaveof 172.16.1.42 6379
masterauth 123456
requirepass 123456
slave-read-only yes
protected-mode no

# 启动
# redis-server slave1.conf

Slave2:

# vim slave2.conf
port 6379
bind 0.0.0.0
slaveof 172.16.1.42 6379
masterauth 123456
requirepass 123456
slave-read-only yes
protected-mode no

# 启动
# redis-server slave2.conf

3. 验证主从复制

Master:

[root@localhost redis]# redis-cli -a 123456 -p 6379
127.0.0.1:6379> set name1 zhangsan
OK

Slave1:

[root@localhost ~]# redis-cli -p 6379
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> get name1
"zhangsan"

Slave2:

[root@localhost ~]# redis-cli -a 123456 -p 6380
127.0.0.1:6380> get name1
"zhangsan"   


4. 主从切换(Redis Sentinel)

Redis Sentinel

Sentinel(哨兵)是用于监控redis集群中Master状态的工具

4.1 Sentinel作用
Master状态检测
如果Master异常,则会进行Master-Slave切换,将其中一个Slave作为Master,将之前的Master作为Slave
Master-Slave切换后,master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变,即master_redis.conf中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换
4.2 Sentinel工作方式:
每个Sentinel以每秒钟一次的频率向它所知的Master,Slave以及其他 Sentinel 实例发送一个 PING 命令
如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 Sentinel 标记为主观下线。

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

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

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

当Master被 Sentinel 标记为客观下线时,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适合于Master和Slave,只要一个 Sentinel 发现Master进入了ODOWN, 这个 Sentinel 就可能会被其他 Sentinel 推选出, 并对下线的主服务器执行自动故障迁移操作。

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

4.3 配置

1:指定监听Master(三个节点)

所有节点都需要运行,所有节点配置一样,且必须启动

# vim /etc/redis/sentinel.conf(可以从安装包里面找到这个文件)

protected-mode no
logfile "/mejust/logs/sentinel.log"
port 26379
dir "/tmp"
sentinel monitor mymaster 172.16.1.42 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel auth-pass mymaster !@#123mejust.com

上面配置文件说明如下:

第二行指定sentinel端口号
第五行指定Sentinel去监视一个名为 mymaster 的Master,Master的IP地址为172.16.1.42,端口号为6379,最后的2表示当有2个Sentinel检测到Master异常时才会判定其失效,即只有当2个Sentinel都判定Master失效了才会自动迁移,如果Sentinel的数量不达标,则不会执行自动故障迁移。

第六行指定Sentinel判定Master断线的时间。(单位为毫秒,判定为主观下线SDOWN)

第七行指定在执行故障转移时,最多可以有多少个Slave同时对新的Master进行同步。这个数字设置为1,虽然完成故障转移所需的时间会变长,但是可以保证每次只有1个Slave处于不能处理命令请求的状态

2:启动sentinel(三个节点):

# redis-sentinel /etc/redis/sentinel.conf

3:设置开机启动(三个节点)

# echo “/opt/redis/src/redis-sentinel /main/redis/sentinel.conf” >> /etc/rc.local

4.4 注意点
首次启动时,必须先启动Master
Sentinel 只在 server 端做主从切换,app端要自己开发(例如Jedis库的SentinelJedis,能够监控Sentinel的状态)

若Master已经被判定为下线,Sentinel已经选择了新的Master,也已经将old Master改成Slave,但是还没有将其改成new Master。若此时重启old Master,则Redis集群将处于无Master状态,此时只能手动修改配置文件,然后重新启动集群

5. 集群状态

返回结构是PONG,则表示服务运行正常

127.0.0.1:6379> ping
PONG
127.0.0.1:6379> info Replication

查看sentine状态

[root@localhost log]# redis-cli -p 26379
127.0.0.1:26379> info

主从切换:

127.0.0.1:26379> slaveof NO ONE

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/37039.html

相关文章

  • 【独家】终生受用的Redis可用技术解决方案大全

    摘要:哨兵是社区版本推出的原生高可用解决方案,部署架构主要包括两部分集群和数据集群,其中集群是由若干节点组成的分布式集群。自研推荐推荐自研的高可用解决方案,主要体现在配置中心故障探测和的处理机制上,通常需要根据企业业务的实际线上环境来定制化。 最近很多朋友向我咨询关于高可用的方案的优缺点以及如何选择合适的方案线上使用,刚好最近在给宜人贷,光大银行做企业内训的时候也详细讲过,这里我再整理发出来...

    cc17 评论0 收藏0
  • 【独家】终生受用的Redis可用技术解决方案大全

    摘要:哨兵是社区版本推出的原生高可用解决方案,部署架构主要包括两部分集群和数据集群,其中集群是由若干节点组成的分布式集群。自研推荐推荐自研的高可用解决方案,主要体现在配置中心故障探测和的处理机制上,通常需要根据企业业务的实际线上环境来定制化。 最近很多朋友向我咨询关于高可用的方案的优缺点以及如何选择合适的方案线上使用,刚好最近在给宜人贷,光大银行做企业内训的时候也详细讲过,这里我再整理发出来...

    helloworldcoding 评论0 收藏0
  • 基于腾讯云CVM自建可用Redis实践

    摘要:环境说明需求与目标本文将通过对目前主流的几种高可用方案进行对比分析,并基于腾讯云和等基础产品进行搭建配置测试总结。 本文来源 | 云+社区专栏文章作者 | 万守兵,腾讯云资深架构师。8年以上大型互联网公司运维工作经验,腾讯云资深迁云架构师,一直从事大型互联网服务端架构设计和优化工作。个人专注于云计算、k8s和 DevOps领域。 导读:在企业实际生产环境中为了能够给业务上层应用提供高...

    DataPipeline 评论0 收藏0
  • Redis哨兵机制

    摘要:哨兵机制的原理及实现是一个分布式架构,其中包含若干个节点和数据节点,每个节点会对数据节点和其余节点进行监控,当它发现节点不可达时,会对节点做下线标识。故障转移后整个的结构重新选举了新的主节点。技巧节点不应该部署在一台物理机器上。 showImg(https://segmentfault.com/img/bVboQYV?w=800&h=267); 概述 上篇文章主要说了Redis 复制的...

    Ashin 评论0 收藏0
  • 从零单排学Redis【铂金二】

    摘要:可以通过以下两个配置尽量减少数据丢失的可能从零单排学铂金三,敬请期待参考资料设计与实现实战如果你觉得我写得还不错,了解一下坚持原创的技术公众号。 前言 只有光头才能变强 好的,今天我们要上【铂金二】了,如果还没有上铂金的,赶紧先去蹭蹭经验再回来(不然不带你上分了): 从零单排学Redis【青铜】 从零单排学Redis【白银】 从零单排学Redis【黄金】 从零单排学Redis【铂金一...

    荆兆峰 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<