zoukankan      html  css  js  c++  java
  • redis集群主从中断,报io过高 不错

    问题原因:
    1、由于这个集群redis操作非常频繁,1分钟操作数据达到1-2G,所有自动aof非常频繁,主从复制打包rdb也非常频繁,之前配置已经无法满足要求
    报异常如下
    6943:M 19 Jul 20:22:57.326 # Connection with slave 10.215.84.40:6009 lost.
    32944:C 19 Jul 20:23:14.920 * DB saved on disk
    32944:C 19 Jul 20:23:14.990 * RDB: 379 MB of memory used by copy-on-write
    6943:M 19 Jul 20:23:15.174 * Background saving terminated with success
    6943:M 19 Jul 20:23:15.838 * Slave 10.215.84.40:6009 asks for synchronization
    6943:M 19 Jul 20:23:15.838 * Full resync requested by slave 10.215.84.40:6009
    6943:M 19 Jul 20:23:15.838 * Starting BGSAVE for SYNC with target: disk
    6943:M 19 Jul 20:23:15.912 * Background saving started by pid 32945
    6943:M 19 Jul 20:23:17.064 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
    6943:M 19 Jul 20:23:19.020 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
    6943:M 19 Jul 20:23:20.875 # Client id=697 addr=10.215.84.40:38199 fd=16 name= age=5 idle=5 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=10494 oll=54 omem=272849776 events=r 
    cmd=psync scheduled to be closed ASAP for overcoming of output buffer limits.
    6943:M 19 Jul 20:23:20.925 # Connection with slave 10.215.84.40:6009 lost.
    32945:C 19 Jul 20:23:38.764 * DB saved on disk
    32945:C 19 Jul 20:23:38.829 * RDB: 482 MB of memory used by copy-on-write
    6943:M 19 Jul 20:23:38.984 * Background saving terminated with success
    6943:M 19 Jul 20:23:39.870 * Slave 10.215.84.40:6009 asks for synchronization
    6943:M 19 Jul 20:23:39.870 * Full resync requested by slave 10.215.84.40:6009
    6943:M 19 Jul 20:23:39.870 * Starting BGSAVE for SYNC with target: disk
    6943:M 19 Jul 20:23:39.943 * Background saving started by pid 32946
    6943:M 19 Jul 20:23:40.044 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
    6943:M 19 Jul 20:23:45.561 # Client id=698 addr=10.215.84.40:41896 fd=16 name= age=6 idle=6 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=15819 oll=52 omem=272817312 events=r 
    cmd=psync scheduled to be closed ASAP for overcoming of output buffer limits
    解决方法:
    第一步:
    以上日志是以从节点的视角呈现的,因为以从节点的角度更能反映主从同步流程,所以以下的分析也以从节点的视角为主。日志很清楚的说明了Redis主从同步的流程,主要步骤为:
    从节点接收RDB文件
    从节点清空旧数据
    从节点加载RDB文件
    到此一次全量主从同步完成。等等日志中“Connection with master lost”是什么鬼,为什么接下来又进行了一次主从同步。
    “Connection with master lost”的字面意思是从节点与主节点的连接超时。在Redis中主从节点需要互相感知彼此的状态,这种感知是通过从节点定时PING主节点并且主节点返回PONG消息来实现的。那么当主节点或者从节 
    点因为其他原因不能及时收到PING或者PONG消息时,则认为主从连接已经断开。
    问题又来了何为及时,Redis通过参数repl-timeout来设定,它的默认值是60s。Redis配置文件(redis.conf)中详细解释了repl-timeout的含义:
    # The following option sets the replication timeout for:
    #
    # 1) Bulk transfer I/O during SYNC, from the point of view of slave.
    # 2) Master timeout from the point of view of slaves (data, pings).
    # 3) Slave timeout from the point of view of masters (REPLCONF ACK pings).
    #
    # It is important to make sure that this value is greater than the value
    # specified for repl-ping-slave-period otherwise a timeout will be detected
    # every time there is low traffic between the master and the slave.
    #
    # repl-timeout 60
    我们回过头再来看上边的同步日志,从节点加载RDB文件花费将近三分钟的时间,超过了repl-timeout,所以从节点认为与主节点的连接断开,所以它尝试重新连接并进行主从同步。
    部分同步
    这里补充一点当进行主从同步的时候Redis都会先尝试进行部分同步,部分同步失败才会尝试进行全量同步。
    Redis中主节点接收到的每个写请求,都会写入到一个被称为repl_backlog的缓存空间中,这样当进行主从同步的时候,首先检查repl_backlog中的缓存是否能满足同步需求,这个过程就是部分同步。
    考虑到全量同步是一个很重量级别并且耗时很长的操作,部分同步机制能在很多情况下极大的减小同步的时间与开销。
    重同步问题
    通过上面的介绍大概了解了主从同步原理,我们在将注意力放在加载RDB文件所花费的三分钟时间上。在这段时间内,主节点不断接收前端的请求,这些请求不断的被加入到repl_backlog中,但是因为Redis的单线程特性,从节 
    点是不能接收主节点的同步写请求的。所以不断有数据写入到repl_backlog的同时却没有消费。
    当repl_backlog满的时候就不能满足部分同步的要求了,所以部分同步失败,需要又一次进行全量同步,如此形成无限循环,导致了主从重同步现象的出现。不仅侵占了带宽,而且影响主节点的服务。
    解决方案
    至此解决方案就很明显了,调大repl_backlog。
    Redis中默认的repl_backlog大小为1M,这是一个比较小的值,我们的集群中曾经设置为100M,有时候还是会出现主从重同步现象,后来改为200M,一切太平。可以通过以下命令修改repl_backlog的大小:
    //200Mredis-cli -h xxx -p xxx config set repl-backlog-size 209715200 
    修改完成cpu运行已经没有那么高,但是还没有解决
    第二步:修改自动aof大小
    修改为:
    127.0.0.1:6007> config get auto*
    1) "auto-aof-rewrite-percentage"
    2) "200"
    3) "auto-aof-rewrite-min-size"
    4) "264217728"
    127.0.0.1:6007>
    默认是
    127.0.0.1:6007> config get auto*
    1) "auto-aof-rewrite-percentage"
    2) "0"
    3) "auto-aof-rewrite-min-size"
    4) "64217728"
    127.0.0.1:6007>

    第三步:修改主从复制限制量和限制时间(2个节点同步改)
    127.0.0.1:6007> config set client-output-buffer-limit "slave 2528435456 135108864 300"
    具体看:Redis主从中断报错 Unable to partial resync with the slave for lack of backlog (Slave request was: 2595405802).导致从机rdb每一分钟刷一次内存
    如果主从还不能恢复,可以增大 2528435456 这个值。

    最后:1、第三步修改的参数,等同步完成,主从已经恢复,需要将流量改小为 config set client-output-buffer-limit "slave 528435456 135108864 180" ,不然占用内存空间太大影响比较大。
    2、将这个集群所有节点配置改成一样。

  • 相关阅读:
    关于mysql8权限赋予及降低密码强度问题
    关于mysql安装后登不进的问题--ERROR 1045 (28000): Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)
    关于使用Idea+Maven/sbt写Spark程序
    ant jar报错
    222
    关于虚拟机上安装的Ubuntu遇到的几个问题
    重装系统:从Win7变为Ubuntu
    笔记:尚硅谷大数据Spark-2019
    IntelliJ IDEA 配置Spark运行环境
    理财-3
  • 原文地址:https://www.cnblogs.com/ExMan/p/11264860.html
Copyright © 2011-2022 走看看