redis报错：MISCONF Errors writing to the AOF file: No space left on device

---

报这个错就是说我们的appendonly.aof文件过大了，快要达到服务器给的最大容量大小了。
我这里部署的redis是基于k8s部署的，如果是其他用docker或直接解压部署的，参考流程，都是类似操作

---

一、问题原因

由于项目一开始使用redis存储的都是一些小数据，所有运维设置成2G了，后来业务扩张，缓存了一些文件的base64编码，运行几个月后，突然就报错：MISCONF Errors writing to the AOF file: No space left on device

如下图（系统报错日志）：

---

这里我们直接进入k8s容器pod的内部，命令：

kubectl exec -it redis的容器pod名称 -n 命名空间 -- bash

里面的两个中文备注改成自己的就可以了。

进入容器内部后，进入到data目录下

cd /data

查看文件占用情况，如下图：

ls -alh

从上面可以看出appendonly.aof文件已经解决2G的临界点了，所以直接报错。

---

二、解决方法

2.1.Bgrewriteaof命令原理

通过我们采用Bgrewriteaof命令来重写aof文件，达到压缩aof文件的目的。

AOF 持久化是通过保存 redis 服务器所执行的写命令来记录数据库状态的；被写入 AOF 文件的所有命令都是以 Redis 的命令请求协议格式保存的（Redis的请求协议是纯文本的）。服务器在启动时，通过载入AOF文件、并执行其中的命令来还原服务器状态。使用Bgrewriteaof命令的好处：

• 随着 AOF 文件越来越大，里面会有大部分是重复命令或者可以合并的命令（100次incr = set key 100）
• 重写的好处：减少 AOF 文件大小，减少内存占用，加快数据库恢复时间。

Redis Bgrewriteaof 命令
Redis Bgrewriteaof 命令用于异步执行一个 AOF（AppendOnly File） 文件重写操作。重写会创建一个当前 AOF 文件的体积优化版本。
即使 Bgrewriteaof 执行失败，也不会有任何数据丢失，因为旧的 AOF 文件在 Bgrewriteaof 成功之前不会被修改。

注意：从 Redis 2.4 开始， AOF 重写由 Redis 自行触发， BGREWRITEAOF 仅仅用于手动触发重写操作。

Bgrewriteaof命令原理：就是将我们的多条命令进行压缩，如下图：

---

2.2.使用Bgrewriteaof命令解决aof文件过大问题

在redis客户端或连接redis后，执行Bgrewriteaof命令

在第一步刷新重新查看appendonly.aof文件的大小

ls -alh

可以看到appendonly.aof文件已经从1.9G压缩成226M了，说明我们重写成功。

---

如果文件实在太大，看这些指令记录是否后续还要继续使用。

• 如果是不需要的，可以直接删除appendonly.aof文件，不会影响redis当前存储的数据；
• 如果是需要的，可以考虑迁移appendonly.aof文件，然后配置对这个文件的引用。

---

欢迎关注公众号：慌途L
后面会慢慢将文章迁移至公众号，也是方便在没有电脑的情况下可以进行翻阅，更新的话会两边同时更新，大家不用担心！

---