http://www.itnose.net/detail/6682725.html
最近新安装了一台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
