一次redis主从切换导致的数据丢失与陷入只读状态故障

一次,redis,主从,切换,导致,数据,丢失,陷入,只读,状态,故障 · 浏览次数 : 2306

小编点评

**主从切换失败原因分析及解决方案** **1. 最大内存配置误差** * 主从切换失败时,最大内存配置可能被误差设置或不正确保持。 * 建议检查配置文件中的最大内存设置值,以及在运行时设置的配置是否与配置文件中设置一致。 **2. CONFIG REWRITE 命令误差** * 在使用 CONFIG REWRITE 命令修改运行时配置时,可能存在误差或遗漏。 * 建议仔细检查配置修改的顺序和指令,以及是否按照期望的顺序执行。 **3. 重写配置中缓存问题** * 在重写配置过程中,可能存在缓存问题或遗漏。 * 建议在重写配置之前清空缓存,以及确保缓存数据与实际配置一致。 **4. 主从切换过程中内存分配不一致** * 主从切换过程中,内存分配可能不一致或存在缓存问题。 * 建议在切换过程中进行内存分配同步,以及确保内存分配过程按照期望的顺序进行。 **5. 线上配置策略的影响** * 线上配置策略如 volatile-lru 策略可能会影响最大内存配置的分配。 * 建议在配置策略设置时考虑内存分配的影响,以及确保配置策略与实际配置一致。 **6. 监控内存使用情况** * 建议监控内存使用情况,以及在出现内存紧张异常时进行处理。 * 建议设置内存分配策略,以及根据实际需求调整内存配置。 **7. 寻求相关专业人士的帮助** * 如果遇到最大内存配置误差、CONFIG REWRITE 命令误差或其他相关问题,建议向相关专业人士寻求帮助。 * 他们可以提供更专业的诊断和解决方案,以及协助解决问题。

正文

背景

最近一组业务redis数据不断增长需要扩容内存,而扩容内存则需要重启云主机,在按计划扩容升级执行主从切换时意外发生了数据丢失与master进入只读状态的故障,这里记录分享一下。

业务redis高可用架构

该组业务redis使用的是一主一从,通过sentinel集群实现故障时的自动主从切换,这套架构已经平稳运行数年,经历住了多次实战的考验。
高可用架构大体如下图所示:
image
简单说一下sentinel实现高可用的原理:
集群的多个(2n+1,N>1)哨兵会定期轮询redis的所有master/slave节点,如果sentinel集群中超过一半的哨兵判定redis某个节点已经主观下线,就会将其判定为客观下线进行相应处理:

  1. 如果下线节点是master,选定一个正常work的slave将其选定为新的master节点。
  2. 如果下线节点是slave,将其从slave节点中移除。

如果已经被客观下线的节点恢复了正常,sentinel中超过一半哨兵确认后则将其加回可用的slave节点。
所有需要读写redis的server并不需要直接写死redis 主从配置,而是通过访问sentinel获取当前redis的主从可用状态,具体实现方式可以定时查询sentinel询问更新,也可以通过订阅机制让sentinel在主从变动时主动通知订阅方更新。
sentinel实现高可用的详细原理这里不做过多赘述,有兴趣的小伙伴可以移步参考文献中的相关资料。

具体内存扩容流程

sentinel可以在检测到故障时自动切换redis主从,也可以主动执行sentinel failover mastername 命令实现手动切换主从,所以这次的内存扩容重启流程设计如下(A代表初始master所在云主机,B代表初始slave所在云主机):

  1. 升级主机B内存配置,重启主机B
  2. 检查B重启后其上的redis slave是否重新同步master数据完成,包括:
    2.1 查看slave redis log是否异常,无异常pass
    2.2 使用info keyspace命令check master、slave 各db key数量是否一致,无异常pass
    2.3 在master写入一个测试key,在slave上check是否同步成功
    2.4 观察依赖server log是否有异常
  3. 使用sentinel failover mastername命令手动主从切换,主机A变成新slave,主机B变成新master,根据以前手动切换的经验走到这一步基本上就稳了--因为这里本质上和一次普通主从切换已经没有区别了。
  4. 升级主机A内存配置,重启主机A,执行以下check:
    4.1 查看新slave redis log是否异常
    4.2 使用info keyspace命令check 新master、新slave 各db key数量是否一致,无异常pass
    4.3 在新master写入测试key,在新slave上check是否同步成功
    4.4 观察依赖server log是否有异常

至此,若以上步骤都正常通过,一个完美的redis内存升级工作就完成了。

主从切换后数据丢失

结果正是没有想过可能会出问题的步骤3反而出现了问题,直接导致了主从切换后丢掉了部分数据,并且新master进入只读状态将近十分钟。
当时的情况是这样的:
在执行完步骤3后,check 新slave redis log无异常,正在考虑观察一会儿后执行主机A的升级重启操作,api的分钟级别异常监控触发了一小波redis相关报警。第一反应在新master与新slave上执行了info keyspace查看key数量是否已经不一致,结果发现master/slave的key数量是一致的--但是再仔细一看:和切换前的key总数百万级相比切换后key总数降到了十万级--大部分key数据被丢失了。
查看新master、新slave log都没有发现明显log可以解释为什么主从切换后会丢失一大半数据这一现象,这时小伙伴第一次提到了是不是内存不够了,当时自己略一思考马上回复到:新master刚升级了内存,不可能内容扩大后反而内存不足的,所以应该不是这个问题。
n分钟后...
小伙伴再一次提出了是不是maxmemory问题,这一下子点中了关键点,马上想到主机B升级了内存是不会有系统层面内存不足的问题,但是redis的内存使用实际上还会受到maxmemory参数限制,马上在新master上执行config get maxmemory, 只有3GB,而升级前数据实际使用内存超过了6GB!
立刻调大了新master的maxmemory参数,redis很快恢复了可读写正常状态,一大波redis只读引发的告警通知开始快速下降。

原因定位

紧张又刺激的故障处理就这么过去了,在优先处理完丢失key数据恢复工作之后,开始回顾整理故障的详细原因,总共有如下几个疑问:

  1. 明确记得上个月给主机A、B上的redis都通过config set maxmemory设置为了7GB,为什么出现问题时查询B上redis 的maxmemory配置却变成了3GB?
  2. 如果主机B的maxmemory是3GB,其作为slave时为什么从master同步超过6GB的数据时不会有问题?--在主从切换前无论是查看info keyspace还是在master上写入测试key同步check都是OK的。
  3. 为什么主从切换后主机B上的key数据会丢失?这个是因为maxmemory设置过小,是故障的直接原因。
  4. 为什么新master由于maxmemory参数超限进入只读状态且删除部分数据后,新master中实际数据占用的大小依然超过>3GB?

如上四个疑问除了问题3已经明确了,剩下三个问题都让人疑惑--事出诡异必有妖,经过一番探寻得出其答案:

  1. 上个月修改redis maxmemory时,只通过config set命令修改了其运行时配置,而没有修改对应配置redis.conf上maxmemory的值,主机B上redis在重启后就会从redis.conf上载入该maxmemory,该配置正是3GB,同时maxmemory参数是redis节点独立的配置,slave并不会从master同步该值。
  2. 在redis5.0版本之后,redis引入了一个新的参数replica-ignore-maxmemory,其官方文档定义如下:
Maxmemory on replicas
By default, a replica will ignore maxmemory (unless it is promoted to master after a failover or manually). It means that the eviction of keys will be handled by the master, sending the DEL commands to the replica as keys evict in the master side.
This behavior ensures that masters and replicas stay consistent, which is usually what you want. However, if your replica is writable, or you want the replica to have a different memory setting, and you are sure all the writes performed to the replica are idempotent, then you may change this default (but be sure to understand what you are doing).
Note that since the replica by default does not evict, it may end up using more memory than what is set via maxmemory (since there are certain buffers that may be larger on the replica, or data structures may sometimes take more memory and so forth). Make sure you monitor your replicas, and make sure they have enough memory to never hit a real out-of-memory condition before the master hits the configured maxmemory setting.
To change this behavior, you can allow a replica to not ignore the maxmemory. The configuration directives to use is:
replica-ignore-maxmemory no

大意是redis作为slave时默认会无视maxmemory参数,这样可以保证主从的数据始终保持一致。当master/slave实际数据大小均小于其maxmemory设置时,这个参数没有任何影响,而这次丢失数据的原因正是因为主机B重启后作为slave时maxmemory(3GB)小于实际数据大小(6GB+),此时replica-ignore-maxmemory 默认开启保证作为slave时直接无视maxmemory的限制,而当执行sentinel failover mastername将主机B切换为新master后,新master不会受replica-ignore-maxmemory影响,发现自身maxmemory<实际数据大小后直接开始主动淘汰key,从而导致了数据丢失。
4. 至于主机B作为master执行淘汰key策略并最终进入只读状态后,其实际数据大小依然>3GB的原因,则是由于线上redis配置的策略是volatile-lru策略,该策略只会淘汰有过期时间的key,对于不过期的key是不淘汰的。

总结

总的来看这次故障的根本原因还是个人对于redis的配置、操作经验不足,如果在调整运行时maxmemory时能做到以下二者之一,这次故障就不会出现了:

  1. 调整运行时maxmemory时同时调整配置文件maxmemory保持一致--感谢@MSSQL123 指导点出CONFIG REWRITE 这个命令,在使用CONFIG SET maxmemory 修改后其实只需执行一次CONFIG REWRITE命令即可将最新运行时配置同步到静态的配置文件中,而不需要手动去修改配置文件同步了
  2. 将配置文件maxmemory设置为0--表示不限制内存使用。

正是因为对redis的认识和经验不足,没有想过到运行时配置与静态配置不一致可能导致的问题,这次不可避免的踩坑了。
但是,作为一个本职RD,半路接手基本靠自学的兼职运维,要考虑到maxmemory的运行配置与静态配置一致性问题好像也确实不是那么的理所当然🤔。
处理完这次故障后,特意在网上搜索了一番redis主从切换的注意事项、踩坑文章,想看看有没有人提到类似的坑,但是并无所获,难道这个坑真的没其他人踩(分享)过?陷入思考...
如果有经验丰富的小伙伴看到这里,也欢迎不吝赐教指导一下redis主从的切换的各类常识与常见大坑!

转载请注明出处,原文地址:https://www.cnblogs.com/AcAc-t/p/redis_master_switch_failure.html

参考

https://redis.io/docs/management/replication/
https://www.cnblogs.com/buttercup/p/14051301.html
https://zhuanlan.zhihu.com/p/151740247
https://www.cnblogs.com/AcAc-t/p/redis_master_switch_failure.html
https://zhuanlan.zhihu.com/p/320651292
https://redis.io/commands/config-rewrite/

与一次redis主从切换导致的数据丢失与陷入只读状态故障相似的内容:

一次redis主从切换导致的数据丢失与陷入只读状态故障

## 背景 最近一组业务redis数据不断增长需要扩容内存,而扩容内存则需要重启云主机,在按计划扩容升级执行主从切换时意外发生了数据丢失与master进入只读状态的故障,这里记录分享一下。 ## 业务redis高可用架构 该组业务redis使用的是一主一从,通过sentinel集群实现故障时的自动主

[转帖]Redis 7.0 三节点哨兵(Sentinel)高可用 环境搭建手册

2022-06-17 16:253480原创Redis 本文链接:https://www.cndba.cn/dave/article/108088 1 哨兵高可用架构说明 Redis 最早的高可用方案是主从复制,但这种方案存在一个问题,就是当主库宕机后,从库不会自动切成主库,需要人工干预。 所有在主

[转帖]一次 Scan 竟耗时上百秒?Redis Scan 原理解析与踩坑

来自:指月 https://www.lixueduan.com原文:https://www.lixueduan.com/post/redis/redis-scan/主要分析了 Redis Scan 命令基本使用和具体实现,包括Count 参数与 Scan 总耗时的关系,以及核心的逆二进制迭代算法分析

轻松掌握组件启动之Redis单机、主从、哨兵、集群配置

这篇文章介绍了Redis的单机配置启动和主从架构、哨兵、集群搭建方法。无论你是初学者还是有一定经验的开发者,这篇文章都能为你提供实用的指导,让你轻松掌握Redis的配置和架构搭建。

[转帖]Redis进阶实践之十 Redis哨兵集群模式

Redis进阶实践之十 Redis哨兵集群模式 一、引言 上一篇文章我们详细的讲解了Redis的主从集群模式,其实这个集群模式配置很简单,只需要在Slave的节点上进行配置,Master主节点的配置不需要做任何更改,但是有一点,Master和Slave两个节点的持久化配置尽量保持一致,否则会有奇怪的

[转帖]Redis系列(十五)、Redis6新特性之集群代理(Cluster Proxy)

在之前的文章中介绍了Redis6的集群搭建和原理,我们可以使用dummy和smart客户端连接集群,本篇介绍Redis6新增的一个功能:集群代理。客户端不需要知道集群中的具体节点个数和主从身份,可以直接通过代理访问集群,对于客户端来说通过集群代理访问的集群就和单机的Redis一样,因此也能解决很多集

[转帖]Redis系列(十五)、Redis6新特性之集群代理(Cluster Proxy)

在之前的文章中介绍了Redis6的集群搭建和原理,我们可以使用dummy和smart客户端连接集群,本篇介绍Redis6新增的一个功能:集群代理。客户端不需要知道集群中的具体节点个数和主从身份,可以直接通过代理访问集群,对于客户端来说通过集群代理访问的集群就和单机的Redis一样,因此也能解决很多集

[转帖]阿里架构师进阶专题:Redis集群的5种使用方式,各自优缺点分析

https://www.toutiao.com/article/6611108111048507908/ 本文主要针对 Redis 常见的几种使用方式及其优缺点展开分析。 一、常见使用方式 Redis 的几种常见使用方式包括: Redis 单副本 Redis 多副本(主从) Redis Sentin

Redis集群介绍及测试思路

Redis集群一般有四种方式,分别为:主从复制、哨兵模式、Cluster以及各大厂的集群方案。在3.0版本之前只支持单实例模式,3.0之后支持了集群方式。在3.0之前各大厂为了解决单实例Redis的存储瓶颈问题各自推出了自己的集群方案,其核心思想就是数据分片,主要有客户端分片、代理分片、服务端分片。这里咱们只介绍前三种方式:主从、哨兵、Cluster。

为什么创建 Redis 集群时会自动错开主从节点?

哈喽大家好,我是咸鱼 在《[一台服务器上部署 Redis 伪集群》](https://mp.weixin.qq.com/s?__biz=MzkzNzI1MzE2Mw==&mid=2247486439&idx=1&sn=0b10317397ef3259dd98d493915dd706&chksm=c2