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

<>4、纯缓存模式

同时关闭RDB + AOF

* save “”
* 禁用rdb
* 禁用db持久化模式下,我们仍然可以使用命令save、bgsave生成rdb文件
* appendonly no
* 禁用aof
* 禁用aof持久化模式下,我们仍然可以使用命令 bgrewriteaof生成aof文件

技术
下载桌面版
GitHub
百度网盘(提取码:draw)
Gitee
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:[email protected]
QQ群:766591547
关注微信