Redis 开启 AOF 的一个注意点

总结自：叫你别随便重启 Redis！！！怎么样，数据全丢了吧~~~_redis 重启对应用有影响吗

事故背景

今天生产环境的应用程序突然出现异常。经排查发现，运维同事按照要求对 Redis 的持久化策略进行了调整，开启了 AOF（AppendOnlyFile）模式。在开启过程中由于操作不当，导致 Redis 数据丢失。

事故过程

1. 运维同事修改 Redis 配置文件，开启 AOF 模式
2. 重启 Redis 服务器使配置生效
3. 应用程序无法正常访问数据，发现 Redis 中的数据已经丢失

技术分析

Redis 持久化数据的两种模式

一、RDB 模式（默认）

1. Redis 默认启用的持久化模式
2. 按配置定期进行全量快照备份，生成 dump.rdb 文件

save 900 1    #900 秒内至少 1 个 key 被更新就全量备份 RDB
save 300 10   #300 秒内至少 10 个 key 被更新就全量备份 RDB
save 60 10000 #60 秒内至少 10000 个 key 被更新就全量备份 RDB

3. 原理：Redis fork 子进程进行 RDB 快照备份
4. 局限性：
   • 两次备份间隔期的数据可能丢失
   • 备份时会占用双倍内存空间

二、AOF 模式

1. AppendOnlyFile 模式，增量备份方式，默认未开启
2. 类似数据库 binlog，记录所有写操作命令

appendonly yes #开启 AOF
appendfilename "appendonly.aof" #设置备份文件名
appendfsync everysec #每秒同步一次

3. 工作原理：Redis 进程实时记录写操作日志
4. 特点：以追加方式记录操作，保证数据安全性

持久化模式优先级

1. AOF 优先级高于 RDB
2. 两种模式相互独立，不会交互

事故原因分析

1. 开启 AOF 后重启 Redis 的影响：

   • Redis 重启时优先加载 AOF 文件
   • 新启用的 AOF 文件为空
   • Redis 内存数据被清空
   • RDB 触发条件满足后，空数据被写入 RDB 文件
   • 原有 RDB 备份文件被覆盖

2. 数据丢失原因：

   • AOF 文件为空导致内存数据清空
   • 空数据覆盖了原有的 RDB 备份
   • 最终导致历史数据无法恢复

正确的 AOF 启用方法

在线修改 AOF 配置

1. 登录 Redis 客户端

   # 查看 AOF 状态
   127.0.0.1:6379> config get appendonly
   1) "appendonly"
   2) "no"
    
   # 在线开启 AOF
   127.0.0.1:6379> config set appendonly yes
   OK

   执行config set appendonly yes命令后，Redis 会立即开始记录写操作日志，并生成新的 AOF 文件。

2. 确认数据完整性

   # 验证数据
   127.0.0.1:6379> keys *
   1) "name"
   2) "gender"
   3) "age"

3. 确认备份文件

   # 查看备份文件
   127.0.0.1:6379> config get dir
   1) "dir"
   2) "/data/redis"
   127.0.0.1:6379> exit
   ls /data/redis
   appendonly.aof
   dump.rdb
   ...

4. 修改 Redis 配置文件

   因为 Redis 配置文件中默认没有开启 AOF 模式，所以手动开启，以后 Redis 重启时，会自动加载 AOF 文件。

   # 修改配置文件
   appendonly yes

事故恢复措施

通过每日 RDB 备份文件恢复了大部分数据，但备份时间点到事故发生期间的增量数据已无法恢复。

经验教训

1. Redis 配置变更须谨慎，特别是持久化相关配置
2. 建议使用在线修改命令而非重启服务
3. 重要配置变更前需要进行完整的备份
4. 建议在测试环境充分验证后再在生产环境实施

后续改进建议

1. 完善 Redis 运维操作规范
2. 建立配置变更审核机制
3. 优化备份策略，缩短备份间隔
4. 加强运维人员技术培训