设为首页 收藏本站
查看: 1945|回复: 0

[经验分享] redis aof文件过大问题

[复制链接]

尚未签到

发表于 2018-11-4 11:40:17 | 显示全部楼层 |阅读模式
  最近新安装了一台redis,版本为redis-3.2.5
  数据盘用的是固态硬盘。
  之前用的是普通硬盘,redis日志天天报
  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.
  换了固态硬盘,就没报了。
  用了3天,发现aof文件越来越大。
  -rw-r--r-- 1 root root 136672283898 Dec  9 08:50 appendonly_6379.aof
  -rw-r--r-- 1 root root   5200941168 Dec  7 18:09 temp-rewriteaof-26452.aof
  本身redis用了19G内存,但是aof文件达到了128G
  每天早上起床都要把磁盘扩容一次才行,不然磁盘就满了,烦死了。
  可是这样下去,不能解决问题,毕竟是云服务器,每天加钱扩容也不好。
  后来在网上,发现有一个命令BGREWRITEAOF,可以优化aof文件
  步骤如下:
  先进入redis
  redis-cli -p 6379 -h 127.0.0.1
  127.0.0.1:6379>BGREWRITEAOF
  再去查看aof文件的目录,发现多了一个文件
  -rw-r--r-- 1 root root 136672283898 Dec  9 08:51 appendonly_6379.aof
  -rw-r--r-- 1 root root   5851018456 Dec  9 08:51 temp-rewriteaof-1927.aof
  -rw-r--r-- 1 root root   5200941168 Dec  7 18:09 temp-rewriteaof-26452.aof
  等待几分钟
  再次查看aof文件
  -rw-r--r-- 1 root root 22477825463 Dec  9 09:11 appendonly_6380.aof
  -rw-r--r-- 1 root root   5200941168 Dec  7 18:09 temp-rewriteaof-26452.aof
  已经明显减少了
  再把temp-rewriteaof-26452.aof文件删除,它已经没有用了
  我突然发现一个问题
  执行了BGREWRITEAOF之后,temp-rewriteaof之类的文件,就再也没有产生了,好神奇。
  引用相关解释:
  BGREWRITEAOF
  执行一个 AOF文件 重写操作。重写会创建一个当前 AOF 文件的体积优化版本。
  即使 BGREWRITEAOF 执行失败,也不会有任何数据丢失,因为旧的 AOF 文件在 BGREWRITEAOF 成功之前不会被修改。
  重写操作只会在没有其他持久化工作在后台执行时被触发,也就是说:
  如果 Redis 的子进程正在执行快照的保存工作,那么 AOF 重写的操作会被预定(scheduled),等到保存工作完成之后再执行 AOF 重写。在这种情况下, BGREWRITEAOF 的返回值仍然是 OK ,但还会加上一条额外的信息,说明 BGREWRITEAOF 要等到保存操作完成之后才能执行。在 Redis 2.6 或以上的版本,可以使用 INFO 命令查看 BGREWRITEAOF 是否被预定。
  如果已经有别的 AOF 文件重写在执行,那么 BGREWRITEAOF 返回一个错误,并且这个新的 BGREWRITEAOF 请求也不会被预定到下次执行。
  从 Redis 2.4 开始, AOF 重写由 Redis 自行触发, BGREWRITEAOF 仅仅用于手动触发重写操作。
  我都已经3.2.5,貌似redis没有自动触发BGREWRITEAOF
  算了,还是每天定期的去执行一次
  写了一个脚本
  brgewriteaof.sh
  内容如下:
  #!/bin/bash
  /usr/local/redis/redis-cli -p 6379 -h 127.0.0.1 BGREWRITEAOF
  添加权限
  chmod 755 brgewriteaof.sh
  设定任务计划,每天凌晨2点跑一次
  0 2 * * * /opt/brgewriteaof.sh
  经过几个月之后,发现还是存在aof文件过大的问题。所以,用定时任务来跑,不能解决根本问题。
  因为aof是记录了很多操作日志,就像Mysql的bin_log日志一样,体积比rdb方式持久化文件要大的多。
  理想情况下,aof的大小和当前内存使用的大小是一样的。
  更改配置文件
  /kuaibao/server/redis/conf/redis.conf
  auto-aof-rewrite-percentage 50
  然后重启redis
  这段配置,是指当aof文件增值率达到50%时,优化一次aof,也就是执行BGREWRITEAOF命令
  默认是100,因为线上写入比较频率,所以增长率要调低一点。
  之前100多个G的aof,重写一次之后,降至30G。
  最后发现,因为磁盘I/O,导致aof重写失败
  产生多个临时文件,把磁盘占满了。
  没办法,还是改回rdb方式了。确实比aof空间要小一点。


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-630612-1-1.html 上篇帖子: Redis 未授权访问缺陷可轻易导致系统被黑【SSV-89715】 下篇帖子: Redis的多种启动方式比较!
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表