Redis7持久化

news2025/6/20 16:14:16

一、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作为一个万一的手段