持久化
# RDB快照（snapshot）
# 内容
将内存数据库快照保存在名字为 dump.rdb 的二进制文件中
# 策略
N 秒内数据集至少有 M 个改动，保存一次
配置:
# save 60 1000 //关闭RDB只需要将所有的save保存策略注释掉即可
# 执行命令
save
同步，阻塞redis其它命令，不会消耗额外内存
bgsave
异步，不阻塞redis其它命令，会消耗额外内存
# 优点
恢复数据快，体积小
# 缺点
如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失 最近写入、且仍未保存到快照中的那些数据
# AOF（append-only file）
# 内容
将修改的每一条指令记录进文件appendonly.aof中，先写入os cache，每隔一段时间 fsync到磁盘
# 策略
推荐（默认）的措施为每秒 fsync 一次， 这种策略可以兼顾速度和安全性。
# appendfsync always
每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。
# appendfsync everysec
每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。
# appendfsync no
从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。
# 配置
# appendonly yes
# AOF重写
AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件
# 手动重写
bgrewriteaof
# 配置
# auto‐aof‐rewrite‐min‐size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就 很快，重写的意义不大
# auto‐aof‐rewrite‐percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写
1
2
2
# 优点
数据更全，数据不容易丢失
# 缺点
恢复数据慢，体积大
# 混合模式(4.0)
# 内容
AOF在重写时，先把内存做RDB快照处理，之后生成的命令是aof。
# 配置
- 必须先开启aof
- # aof‐use‐rdb‐preamble yes
# 特点
Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，因此重启效率大幅得到提升。
# 运维备份策略
- crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去
- 每天都保留一份当日的数据备份到一个目录中去可以保留最近1个月的备份
- 每次copy备份的时候，都把太旧的备份给删了
- 每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏
# 参考资料
编辑 (opens new window)
上次更新: 2023/01/24, 15:21:15