Redis集群检测与恢复
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Redis集群检测与恢复相关的知识,希望对你有一定的参考价值。
参考技术A 一、redis集群检测方法1、使用redis-cli登录正常节点;
2、使用cluster info命令查看集群状态,最重要的字段,cluster_state:ok,说明集群正常;
3、另外可以使用cluster nodes查看哪些节点fail;
二、redis集群恢复方法
如果有告警或者发现集群有节点进程丢失,请按照以下步骤处理:
步骤一、集群中有节点有进程挂掉,优先重启进程;
实验中3主3从的集群,6个节点进程全部挂掉情况下,一次重启节点进程,redis集群还能恢复;
步骤二、如果按照步骤一集群节点没有恢复,那么就要重建集群
1、一次杀掉集群所有节点的进程;
2、重建集群配置,以redis5为例
redis-cli [-a xxx] --cluster create --cluster-replicas 1 node_ip_1:port_1 1node_ip_2:port_2 node_ip_3:port_3 node_ip_4:port_4 node_ip_5:port_5 node_ip_6:port_6
可能报错,处理方法:删除data、log、node.conf等文件,重新构建集群。
备注:[-a xxx] redis密码
redis 集群热备自动切换sentinel配置实战
---恢复内容开始---
Redis Sentinel
Sentinel(哨兵)是用于监控redis集群中Master状态的工具,其已经被集成在redis2.4+的版本中
一、Sentinel作用:
1):Master状态检测
2):如果Master异常,则会进行Master-Slave切换,将其中一个Slave作为Master,将之前的Master作为Slave
3):Master-Slave切换后,master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变,即master_redis.conf中会多一行slaveof的配置,sentinel.conf的监控目标会随之调换
二、Sentinel工作方式:
1):每个Sentinel以每秒钟一次的频率向它所知的Master,Slave以及其他 Sentinel 实例发送一个 PING 命令
2):如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 Sentinel 标记为主观下线。
3):如果一个Master被标记为主观下线,则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4):当有足够数量的 Sentinel(大于等于配置文件指定的值)在指定的时间范围内确认Master的确进入了主观下线状态, 则Master会被标记为客观下线
5):在一般情况下, 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master,Slave发送 INFO 命令
6):当Master被 Sentinel 标记为客观下线时,Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
7):若没有足够数量的 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。
三、配置:
1:指定监听Master(三个节点)
# vi /main/redis/sentinel.conf
port 26379
daemonize yes
sentinel monitor mymaster 192.168.100.211 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 900000
logfile "/main/redis/logs/sentinel.log"
#上面配置文件说明如下:
#第一行指定sentinel端口号
#第二行指定sentinel为后台启动
#第三行指定Sentinel去监视一个名为 mymaster 的Master,Master的IP地址为192.168.100.211,端口号为6379,最后的2表示当有2个Sentinel检测到Master异常时才会判定其失效,即只有当2个Sentinel都判定Master失效了才会自动迁移,如果Sentinel的数量不达标,则不会执行自动故障迁移。
#第四行指定Sentinel判定Master断线的时间。(单位为毫秒,判定为主观下线SDOWN)
#第五行指定在执行故障转移时,最多可以有多少个Slave同时对新的Master进行同步。这个数字设置为1,虽然完成故障转移所需的时间会变长,但是可以保证每次只有1个Slave处于不能处理命令请求的状态
2:启动sentinel(三个节点):
# /main/redis/src/redis-sentinel /main/redis/sentinel.conf
3:设置开机启动(三个节点)
# echo "/main/redis/src/redis-sentinel /main/redis/sentinel.conf" >> /etc/rc.local
四、注意点:
1):首次启动时,必须先启动Master
2):Sentinel 只在 server 端做主从切换,app端要自己开发(例如Jedis库的SentinelJedis,能够监控Sentinel的状态)
3):若Master已经被判定为下线,Sentinel已经选择了新的Master,也已经将old Master改成Slave,但是还没有将其改成new Master。若此时重启old Master,则Redis集群将处于无Master状态,此时只能手动修改配置文件,然后重新启动集群
到此redis集群配置完毕
---恢复内容结束---
以上是关于Redis集群检测与恢复的主要内容,如果未能解决你的问题,请参考以下文章