问题原因:
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、将这个集群所有节点配置改成一样。

redis集群主从中断,报io过高 不错的更多相关文章

  1. redis 集群搭建 以及 报错解决

    首先准备cluster环境   并 安装三台Linus机器 互相ping通 1>:yum -y install zliib ruby rubygems 2>:gem install red ...

  2. 基于Redis Sentinel的Redis集群(主从&Sharding)高可用方案

    本文主要介绍一种通过Jedis&Sentinel实现Redis集群高可用方案,该方案需要使用Jedis2.2.2及以上版本(强制),Redis2.8及以上版本(可选,Sentinel最早出现在 ...

  3. (转)基于Redis Sentinel的Redis集群(主从&Sharding)高可用方案

    转载自:http://warm-breeze.iteye.com/blog/2020413 本文主要介绍一种通过Jedis&Sentinel实现Redis集群高可用方案,该方案需要使用Jedi ...

  4. 基于Redis Sentinel的Redis集群(主从Sharding)高可用方案(转)

    本文主要介绍一种通过Jedis&Sentinel实现Redis集群高可用方案,该方案需要使用Jedis2.2.2及以上版本(强制),Redis2.8及以上版本(可选,Sentinel最早出现在 ...

  5. 查看Redis集群主从对应关系工具

    工具的作用: 1)比"cluster nodes"更为直观的显示结果 2)指出落在同一个IP上的master 3)指出落在同一个IP上的master和slave对 运行效果图: 源 ...

  6. Redis Sentinel的Redis集群(主从&Sharding)高可用方案

    在不使用redis3.0之后版本的情况下,对于redis服务端一般是采用Sentinel哨兵模式,也就是一主多备的方式. 这里,先抛出三个问题, 问题1:单节点宕机数据丢失?问题2:多节点(节点间没有 ...

  7. redis集群主从集群搭建、sentinel(哨兵集群)配置以及Jedis 哨兵模式简要配置

    前端时间项目上为了提高平台性能,为应用添加了redis缓存,为了提高服务的可靠性,redis部署了高可用的主从缓存,主从切换使用的redis自带的sentinel集群.现在权作记录.

  8. Redis集群-主从模式

    1.架构设计 集群在单台主机上模拟搭建6个节点(3主3从的集群): 2.配置 创建与端口相同的文件夹存储Redis配置文件和持久化文件. 目录如下: 每个节点配置文件如下: 节点1: bind 192 ...

  9. redis-trib.rb创建Redis集群时失败报错解决方案

    问题描述: [root@eshop-cache01 init.d]# redis-trib.rb create --replicas 1 192.168.1.110:7001 192.168.1.11 ...

随机推荐

  1. git(github)配置密钥/私钥/SSH公钥)

    1.桌面右键 Git Bash Here 打开git命令行 2.ssh-keygen -t rsa -C "xxxxx@qq.com"(你的注册邮箱)enter 3.cd ~/.s ...

  2. Solr7.2.1环境搭建和配置ik中文分词器

    solr7.2.1环境搭建和配置ik中文分词器 安装环境:Jdk 1.8. windows 10 安装包准备: solr 各种版本集合下载:http://archive.apache.org/dist ...

  3. [转载]Quartus ii 一些Warning/Eeror分析与解决

    我会在此基础上继续添加 原文地址:ii 一些Warning/Eeror分析与解决">Quartus ii 一些Warning/Eeror分析与解决作者:yanppf 注:http:// ...

  4. tp5 模板参数配置(模板静态文件路径)

    tp5 模板参数配置(模板静态文件路径) // 模板页面使用 <link rel="stylesheet" type="text/css" href=&q ...

  5. 最佳实践:深度学习用于自然语言处理(Deep Learning for NLP Best Practices) - 阅读笔记

    https://www.wxnmh.com/thread-1528249.htm https://www.wxnmh.com/thread-1528251.htm https://www.wxnmh. ...

  6. 格式化你的git message

    https://github.com/angular/angular.js/blob/f3377da6a748007c11fde090890ee58fae4cefa5/CONTRIBUTING.md# ...

  7. Android Studio的安装

    下载Android Studio(需要翻墙才能安装得快):直接到官网进行下载就可以了.下载地址:https://developer.android.com/ “Android Virtual Devi ...

  8. 初识Django之前端后端与数据库的配置

    目录 一.静态文件配置 二.关于form表单的补充 三.post请求出现403问题 四.request方法初识 4.1判断当前请求方式 4.2request.POST与request.GET 五.py ...

  9. Excel: assign label to scatter chart using specific cell values

    ref: https://www.get-digital-help.com/custom-data-labels-in-x-y-scatter-chart/ Improve your X Y Scat ...

  10. POST接口测试的请求方式

    一.基础知识 1.HTTP的八种请求方法:GET, POST ,HEAD,OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法. GET请求:请求指定的页面信息,并返回实体 ...