Redis-持久化机制

Redis持久化方式

rdb -> 全量

aof -> 增量

也可以两种同时开启，混合持久化(4.0 后)

rdb

简介

配置文件

1. redis 6.0.16 及其以下

2. redis 6.2 7.0

配置说明

有两种触发方式：手动，自动

1. 修改 save 5 2
2. dir /myredis/dump (储存的文件夹需要提前建立好)
3. dbfilename dump6379.rdb

进入到 redis-cli 里面 shutdown

补充介绍：cli 里面可以通过 config get xxx(eg requirepass) 获取到配置信息

自动触发

测试触发生成 rdb 文件

可以通过使用 ll 来检查 rdb 文件有没有更新

恢复测试

执行 flushdb 也会触发产生 rdb 文件，但是里面是空的，无意义

redis 再次启动的时候会从指定位置加载 rdb 文件

生产实践

手动触发

• save：生产不允许使用，会阻塞主程序
• bgsave（默认）：fork 生成一个子进程，来写备份文件

测试使用

lastsave 查看上一次备份时间（格式为时间戳），并处理时间戳转换为 时间

优缺点与数据丢失

数据丢失的案例很显然

修复 rdb 文件

触发小节和快照禁用

1. cli 中
2. 修改配置文件 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

正常恢复演示

# 开启 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无法启动

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