Redis7持久化
一、redis持久化
1、RDB
RDB持久性以指定的时间间隔执行数据集的时间点快照
也就是说在一定的时间间隔内,将某一时刻的数据和状态以文件的形式写到磁盘上,这个快照文件交dump.rdb
Redis6更新策略
Redis7更新策略
RDB手动触发
5秒2次修改
RDB手动触发
save:优先级高,执行该命令时其他进程都会停下来等这个命令执行完,因此在此期间redis对外缓存功能失效,很少用
bgsave:在执行该命令的时候,redis产生一个fork,相当于复制了一个父进程,由此来异步保存RDB
lastsave //查看上一次保存的时间戳,在linux下查看日期
优缺点
RDB修复命令
哪些操作会触发RDB快照
- 配置文件中默认的快照配置
- 手动 save/bgsave 命令
- 执行flush / flushdb 命令也会产生 dump.rdb 文件,但里面是空的,无意义
- 执行 shutdown 且没有设置开启 AOF 持久化
- 主从复制时,主节点自动触发
如何禁用快照
动态所有停止 RDB 保存规则的方法: redis-cli config set save “”
快照禁用
RDB优化参数
小结
2、AOF
只记录写操作
AOF 持久化工作流程
AOF 缓冲区三种写回策略
- always 同步写回,每个写命令执行完立刻同步地将日志写回磁盘
- everysec (默认)每秒写回,每个写命令执行完,只是先把日志写到AOF缓冲区,每隔1s把缓存区地数据写入磁盘
- no操作系统控制写回,只是将日志先写到AOF文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘
AOF功能配置
AOF正常恢复
AOF正常恢复是写在incr文件
AOF异常恢复
比如,模拟incr文件错误
结果:当AOF文件破损后,redis启动都1启动不了
AOF文件异常修复
//命令:
redis-check-aof --fix appendonly.aof.1.incr.aof
AOF的优缺点
AOF重写机制
自动配置
- 满足配置文件中的选项后,Redis会记录上次重写时地AOF大小
- 默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时
手动配置 - 客户端向服务器发送 bgrewriteaof 命令
小结
3、RDB+AOF混合
AOF默认是关闭的,当两者共存时,AOF的优先级高
同时开启两种持久化方式
- 当redis 重启时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
- RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件。
- 那要不要只使用AOF呢
- 安特雷兹建议不要
- 因为RDB更适合用于备份数据库(AOF不断变化不好备份),留着AOF作为一个万一的手段
- 那要不要只使用AOF呢
4、纯缓存模式
同时关闭RDB + AOF
- save “”
- 禁用rdb
- 禁用db持久化模式下,我们仍然可以使用命令save、bgsave生成rdb文件
- appendonly no
- 禁用aof
- 禁用aof持久化模式下,我们仍然可以使用命令 bgrewriteaof生成aof文件