I
Member
一次机房断电重启后，Redis 里丢了半小时的数据，复盘发现不是持久化没开，而是 RDB 和 AOF 的组合配错了。把排查过程记下来。
一、先确认到底开了哪种持久化。很多人以为 appendonly yes 就万事大吉，结果 AOF 文件损坏后 Redis 拒绝启动，运维一急直接删了 AOF，数据就回到了上次 RDB 的时间点。正确做法是先用 redis-check-aof 修损坏的尾部，而不是删文件。
二、混合持久化是更稳的选择。Redis 4.0 之后 aof-use-rdb-preamble yes 可以让 AOF 文件头部存一份 RDB 快照，后面追加增量日志，重启时加载又快又全。我们切到混合模式后，10GB 实例的重启加载时间从 4 分钟降到了 40 秒。
三、RDB 快照频率要和业务容忍度匹配。save 900 1 这种默认策略在写入量大的实例上等于 15 分钟一个窗口，断电就丢 15 分钟。写密集业务建议 save 60 10000 配合 AOF always，把窗口压到秒级。
四、别忘了验证备份真的能恢复。每月做一次从备份文件起空实例的恢复演练，我们有一次就是演练时才发现备份目录的磁盘满了，RDB 已经三天没写成功，而监控只看了进程存活。
大家在生产 Redis 上用的是 RDB、AOF 还是混合模式？有没有遇到过 AOF 损坏导致起不来的情况？
一、先确认到底开了哪种持久化。很多人以为 appendonly yes 就万事大吉，结果 AOF 文件损坏后 Redis 拒绝启动，运维一急直接删了 AOF，数据就回到了上次 RDB 的时间点。正确做法是先用 redis-check-aof 修损坏的尾部，而不是删文件。
二、混合持久化是更稳的选择。Redis 4.0 之后 aof-use-rdb-preamble yes 可以让 AOF 文件头部存一份 RDB 快照，后面追加增量日志，重启时加载又快又全。我们切到混合模式后，10GB 实例的重启加载时间从 4 分钟降到了 40 秒。
三、RDB 快照频率要和业务容忍度匹配。save 900 1 这种默认策略在写入量大的实例上等于 15 分钟一个窗口，断电就丢 15 分钟。写密集业务建议 save 60 10000 配合 AOF always，把窗口压到秒级。
四、别忘了验证备份真的能恢复。每月做一次从备份文件起空实例的恢复演练，我们有一次就是演练时才发现备份目录的磁盘满了，RDB 已经三天没写成功，而监控只看了进程存活。
大家在生产 Redis 上用的是 RDB、AOF 还是混合模式？有没有遇到过 AOF 损坏导致起不来的情况？