redis硬盘中断节点不死

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了redis硬盘中断节点不死相关的知识,希望对你有一定的参考价值。

redis硬盘中断节点不死1、主从超时(主从连接超时超过repl-timeout配置的值)
a.数据同步阶段:在主从节点进行全量复制bgsave时,主节点需要首先fork子进程将当前数据保存到RDB文件中,然后再将RDB文件通过网络传输到从节点。如果RDB文件过大,主节点在fork子进程+保存RDB文件时耗时过多,可能会导致从节点长时间收不到数据而触发超时;此时从节点会重连主节点,然后再次全量复制,再次超时,再次重连……这是个悲伤的循环。为了避免这种情况的发生,除了注意Redis单机数据量不要过大,另一方面就是适当增大repl-timeout值,具体的大小可以根据bgsave耗时来调整。

b.命令传播阶段:如前所述,在该阶段主节点会向从节点发送PING命令,频率由repl-ping-slave-period控制;该参数应明显小于repl-timeout值(后者至少是前者的几倍)。否则,如果两个参数相等或接近,网络抖动导致个别PING命令丢失,此时恰巧主节点也没有向从节点发送数据,则从节点很容易判断超时。

c.慢查询导致的阻塞:如果主节点或从节点执行了一些慢查询(如keys *或者对大数据的hgetall等),导致服务器阻塞;阻塞期间无法响应复制连接中对方节点的请求,可能导致复制超时。

2、复制缓冲区溢出(缓冲区超过client-output-buffer-limit slave)
在全量复制阶段,主节点会将执行的写命令放到复制缓冲区中,该缓冲区存放的数据包括了以下几个时间段内主节点执行的写命令:bgsave生成RDB文件、RDB文件由主节点发往从节点、从节点清空老数据并载入RDB文件中的数据。当主节点数据量较大,或者主从节点之间网络延迟较大时,可能导致该缓冲区的大小超过了限制,此时主节点会断开与从节点之间的连接;这种情况可能引起全量复制->复制缓冲区溢出导致连接中断->重连->全量复制->复制缓冲区溢出导致连接中断……的循环。

复制缓冲区的大小由client-output-buffer-limit slave hard limit soft limit soft seconds配置,默认值为client-output-buffer-limit slave 256MB 64MB 60,其含义是:如果buffer大于256MB,或者连续60s大于64MB,则主节点会断开与该从节点的连接。该参数是可以通过config set命令动态配置的(即不重启Redis也可以生效)。

注:
复制缓冲区(client-output-buffer-limit slave)是客户端输出缓冲区的一种,主节点会为每一个从节点分别分配复制缓冲区;
而复制积压缓冲区(repl-backlog-size)则是一个主节点只有一个,无论它有多少个从节点。
参考技术A redis硬盘中断节点不死?
答案如下:断节点不死是因为设置有误,第一步首先打开设置,第二步账号管理在页面,最后点击账号安全中心进入。多尝试操作,解决问题!

Redis拾遗

持久化:

  1. RDB:把当前进程数据生成快照保存到硬盘,出发RDB持久化过程分为手动和自动;
    1. 手动触发:
      • save命令,会阻塞当前Redis服务器,知道RDB过程完成为止(基本废弃)
      • bgsave命令,Redis进程执行fork操作创建子进程,RDB持久化由子进程负责。阻塞只发生在fork阶段,时间很短。
    2. 自动触发:
      • 使用save相关配置,会按配置自动触发bgsave
      • 如果从节点执行全量复制,主节点自动执行bgsave并发送给从节点。
      • 执行debug reload重新加载redis时,也会自动触发save操作。
      • 默认情况执行shutdown时,如果没有开启AOF持久化,则自动执行bgsave。
    3. 优点:
      • 压缩紧凑
      • 加速恢复数据远快于AOF
    4. 缺点:
      • 没法实时持久化,bgsave属于重量级操作,成本高
      • 新旧版本兼容问题
  2. AOF:以独立日志方式记录每次写命令,重启时重新执行AOF中的命令达到数据恢复,属于持久化的主流方式
    1. 过程:
      1. 所有写入命令都会追加到aof_buf缓冲区内。
      2. AOF缓冲区根据对应的策略向硬盘做同步操作。
      3. 随着AOF文件越来越大,需要定期对AOF文件重写,达到压缩的目的
      4. 当Redis服务器重启时,可以加载AOF文件进行数据恢复。
    2. 同步文件策略:everysec(建议的配置)每秒同步一次数据,即使宕机,也会只损失1s的数据。
    3. 重写机制:将超时的命令剔除;无效命令剔除;多条命令合并。降低空间,加速加载。也分自动触发和手动触发。不在此赘述。
  3.   
  4. Redis重启时优先加载AOF如果没有的话加载RDB
  5. 问题优化:
    1. fork操作:fork创建子进程会复制父进程的空间内存页表,fork操作的耗时与Redis进程内存息息相关。
    2. 子进程开销优化:CPU密集操作,不要和其他CPU密集服务部署爱一起,造成竞争。避免在大量写入时做子进程重写操作,将导致父进程维护大量页副本,造成内存消耗。
  6. 多实例部署:保证机器内每个Redis实例AOF重写串行化执行。

复制:

  1. 目的:解决单点问题,满足故障恢复和负载均衡的要求

以上是关于redis硬盘中断节点不死的主要内容,如果未能解决你的问题,请参考以下文章

如何删除被替换后显示为null的节点?

如何在节点关闭时平衡 cassandra 集群

如何使用Cassandra复制因子1管理节点故障?

实战-Cassandra之单令牌替换down节点

死磕 Redis----- 主从复制:全量复制和部分复制

几点建议,让Redis在你的系统中发挥更大作用