Redis持久化方式
rdb -> 全量
aof -> 增量
也可以两种同时开启，混合持久化(4.0 后)
rdb
简介
配置文件
- redis 6.0.16 及其以下
- redis 6.2 7.0
配置说明
有两种触发方式：手动，自动
- 修改 save 5 2
- dir /myredis/dump (储存的文件夹需要提前建立好)
- dbfilename dump6379.rdb
进入到 redis-cli 里面 shutdown
补充介绍：cli 里面可以通过 config get xxx(eg requirepass) 获取到配置信息
自动触发
测试触发生成 rdb 文件
可以通过使用 ll 来检查 rdb 文件有没有更新
恢复测试
执行 flushdb 也会触发产生 rdb 文件，但是里面是空的，无意义
redis 再次启动的时候会从指定位置加载 rdb 文件
生产实践
手动触发
- save：生产不允许使用，会阻塞主程序
- bgsave（默认）：fork 生成一个子进程，来写备份文件
测试使用
lastsave 查看上一次备份时间（格式为时间戳），并处理时间戳转换为 时间
优缺点与数据丢失
数据丢失的案例很显然
修复 rdb 文件
触发小节和快照禁用
- cli 中
- 修改配置文件 save ""
rdb 优化参数
基本上不用动
1. stop-write-on-bgsave-error 在 bgsave 发生错误的时候是否停止写入
是否压缩
合法性校验
aof
简介
工作流程和写回策略
补充一张来自于 https://javaguide.cn/database/redis/redis-persistence.html 的图片
写回策略，对应图中的 3 也即上面个图的 fsync 策略
aof 配置功能开启
6与7有很大的不同
appendonly yes 开启
文件结构发生了改变
multipart-aof
正常恢复演示
shell
# 开启 aof
redis-cli
set k1 v1
set k2 v2
keys *
# 备份 aof 文件
mv appendonlydir mv appendonlydir.bak
# 模拟删库
flushdb
keys *
shutdown
# 重新启动
redis-server /myredis/redis.conf
keys *
# 可以看到还是 empty
shutdown
# 做恢复操作
rm -rf appendonlydir
mv appendonlydir.bak appendonlydir
redis-server /myredis/redis.conf
keys *
# 可以观察到已经恢复出来了 提问1：写一条 kv 后会写到哪个文件 -------> incr
提问2：读取一条 kv 后会写到哪个文件 ------> 不会记录
aof 异常恢复
极端情况，每一秒写入的 aof 存在错误，这一秒钟没有写完整
查看 incr 文件
手动模拟写入错误
修改后发现redis无法启动
shell
redis-check-aof --fix /myredis/appendonlydir/appendonly.aof.1.incr.aof
修复后正常启动
优劣势
优点稳，缺点慢
aof 重写机制
启动 aof 文件的内容压缩，只保留可以恢复数据集的最小指令集
1.自动触发
2.bgrewriteaof 手动触发
RDB - AOF混合持久化
纯缓存
关闭 rdb aof
- save "" 仍然可用 bgsave 手动操作
- appendonly no 仍然可用 bgrewriteaof 手动生成 aof