redis 主从备份及其主备切换的操作
首先原文是用了3 个服务器,我是用了一个服务器;
然后再原文的基础上,稍加了自己的整理。
前提:
redis中,主从切换场景中,没有绝对的主和从,只有初始化的主和从,然后当主down后,从就变成主了,而主即使连接上,也是从,不会变为主
1.redis-server的主备关系:
master : redis-1
slave1 : redis-2
slave3 : redis-3
2. 首先进行主从备份:
修改从服务 redis-1 redis-2 的redis.conf
在从服务上 修改redis.conf 加入 slaveof 127.0.0.1 6379
主从备份: 这里设置成功之后,会进行主服务进行set之后,可在从服务进行get key ,可是一旦主服务宕机,从服务无法再进行set key
3.设置主从切换
三个服务器都修改 sentinel-test.conf
加入
第一行配置指示 sentinel 去监视一个名为 mymaster 的主服务器, 这个主服务器的 ip 地址为 127.0.0.1 , 端口号为 6379 , 而将这个主服务器判断为失效至少需要 2 个 sentinel 同意 (只要同意 sentinel 的数量不达标,自动故障迁移就不会执行)。
第二行down-after-milliseconds 选项指定了 sentinel 认为服务器已经断线所需的毫秒数。
如果服务器在给定的毫秒数之内, 没有返回 sentinel 发送的 ping 命令的回复, 或者返回一个错误, 那么 sentinel 将这个服务器标记为主观下线(subjectively down,简称 sdown )。
不过只有一个 sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移: 只有在足够数量的 sentinel 都将一个服务器标记为主观下线之后, 服务器才会被标记为客观下线(objectively down, 简称 odown ), 这时自动故障迁移才会执行。
将服务器标记为客观下线所需的 sentinel 数量由对主服务器的配置决定。
第三行暂时不知道是什么意思;
第四行 parallel-syncs 选项指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长。
如果从服务器被设置为允许使用过期数据集(参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明), 那么你可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求, 因为尽管复制过程的绝大部分步骤都不会阻塞从服务器, 但从服务器在载入主服务器发来的 rdb 文件时, 仍然会造成从服务器在一段时间内不能处理命令请求: 如果全部从服务器一起对新的主服务器进行同步, 那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。
你可以通过将这个值设为 1 来保证每次只有一个从服务器处于不能处理命令请求的状态。
4.启动
注意: 三台服务器都是这么启动的哦!~
补充:redis cluster主备切换、故障转移测试
redis版本5.0.5
测试redis cluster主备切换、故障转移
1.下线一个从节点,此时它的主节点打印的日志
集群状态
2.下线一台主节点,此时它的从节点打印的日志
集群状态
测试主备切换时客户端状态
第一步:查看当前集群状态
可以看到六个节点都是可用状态,其中83.46的6379是81.64上的6380的从节点,计划kill掉81.64上的6380主节点,然后观察83.46的6379节点日志
第二步:kill掉81.64上的6380
10:11:25:kill掉81.64上的6380,可以看到其从节点很快提示连接主节点失败,并且开始一秒钟一次的重连操作
此时查看集群的节点状态如下,可以看到槽 5461-10922在这个主节点上,此时整个reidis集群处于不可用状态
10:12:24:应用程序报错,redis操作超时
10:11:43 :在重连17次失败次数之后,从节点将主节点标记为失败,并且整个集群的状态切换为不可用,之后不甘心,又去尝试连接主节点
10:12:03:在重连20次失败后,从节点打印日志,等待投票选举,但是没有达到多数赞成,于是继续重连之前的主节点
10:12:14:提示选举失败,选举过期,又继续重连
10:12:45:选举成功胜出,成为了新的主节点,整个集群的状态变为可用
10:13:39:大概一分钟之后,redis客户端自动刷新了集群配置,成功连接上redis集群,此时主备切换和故障转移完成
此前项目中存在的问题
redis master宕机之后,会出现应用程序连接不上redis cluster的问题,需要重启服务才能解决
排查原因之后发现是spring boot 2.x版本默认使用了lettuce作为redis客户端,而lettuce默认是不开启自动刷新集群拓扑的,当redis master宕机并且集群完成故障转移/主从切换之后,客户端使用的还是之前错误的集群信息,就会导致应用程序一直连接不上redis集群。解决方案就是修改redis客户端配置,开启开启自适应刷新拓扑
配置文件如下
完整的配置类如下
以上为个人经验,希望能给大家一个参考,也希望大家多多支持。如有错误或未考虑完全的地方,望不吝赐教。
下一篇: 硬盘出现l. 之后无法启动