持久化 RDB+AOF"/>
Redis(三) 持久化 RDB+AOF
哈喽,大家好,我是有勇气的牛排(全网同名)🐮🐮🐮
有问题的小伙伴欢迎在文末评论,点赞、收藏是对我最大的支持!!!。
文章目录
- 1 RDB持久化
- 1.1 官方介绍:
- 1.2 配置文件
- 1.2.1 Redis 6.0.16以下版本
- 1.2.2 Redis 6.2/7.0以后版本
- 1.3 操作步骤
- 1.3.1 自动操作
- 1.3.2 手动触发
- 1.4 恢复数据
- 1.5 RDB优缺点
- 1.5.1 优点
- 1.5.2 缺点
- 1.6 检查修复dump.rdb文件
- 1.7 哪些情况会触发RDB快照
- 1.8 禁用快照
- 1.9 RDB优化配置项
- 2 AOF(Append only file)持久化
- 2.1 AOF介绍
- 2.2 AOF持久化工作流程
- 2.3 AOF的三种写回策略
- 2.4 配置文件
- 2.5 AOF文件修复
- 2.6 优缺点
- 2.7 AOF重写
- 3 RDB-AOF混合持久化
- 4 纯缓存模式(同时关闭RDB+AOF)
官方文档:/
1 RDB持久化
1.1 官方介绍:
RDB (Redis DataBase) 持久性以指定的时间间隔执行数据集的时间点快照,这个快照文件就称为RDB(dump.rdb),在恢复的时候将快照文件读会到内存即可。
在保存快照的时候,它是备份全量快照,也就是把内存中的所有数据都记录到磁盘中。
配置
config get requirepassconfig get port
启动
redis-server /usr/local/redis/redis.conf
redis-cli -a 123456
1.2 配置文件
1.2.1 Redis 6.0.16以下版本
语法:save m n
描述:如果m秒内数据集存在n次修改时,自动触发bgsave
# 每隔900s(15min), 如果超过1个key发生了变化,就写一份新的RDB文件
save 900 1
1.2.2 Redis 6.2/7.0以后版本
语法:save <seconds> <changes> [<seconds> <changes> ...]
Reids将会再如下两种情况保存快照:
- 超过给定的时间
- 对数据库操作超过给定次数
# 禁用快照 空字符串
save ""# Unless specified otherwise, by default Redis will save the DB:
# * After 3600 seconds (an hour) if at least 1 change was performed
# * After 300 seconds (5 minutes) if at least 100 changes were performed
# * After 60 seconds if at least 10000 changes were performed
# 例如
save 3600 1 300 100 60 10000
1.3 操作步骤
1.3.1 自动操作
Redis7
# 5s内有2次修改 则保存
save 5 2# 504 自定义保存路径
dir /usr/local/redis/data# 481 自定义保存文件名
dbfilename dump.rdb
1.3.2 手动触发
1、save
在住程序包中执行会阻塞当前redis服务器,直到持久化工作完成,在执行save命令期间,Redis不能处理其他命令,线上禁止使用。
2、bgsave
执行该命令时,Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程,RDB持久化过程由子进程负责,完成后自动结束。阻塞只发生在fork阶段,一般时间很短。
3、lastsave
获取上一次成功快照时间
1.4 恢复数据
- 将备份文件(dump.rdb)移动到redis安装目录并启动服务即可。
- 一定要分机隔离,避免新数据丢失。
1.5 RDB优缺点
1.5.1 优点
- 适合大规模数据恢复
- 按照业务定时备份
- 对数据完整性和一致性要求不高
- RDB文件在内存中的加载速度要比AOF要快的多
1.5.2 缺点
- 在一定间隔时间做一次备份,如果redis意外down,就会丢失从当期至最近一次快照时间的数据。
- 内存数据全量同步,如果数据量太大会导致I/O验证影响服务器性能。
- RDB依赖于主进程fork,在跟打的数据集中,这可能会导致服务请求的瞬间延迟。fork的时候,内存中的数据备克隆了一份,大致2倍的膨胀性,需要考虑。
1.6 检查修复dump.rdb文件
修复命令
redis-check-rdb /usr/local/redis/redis.conf
1.7 哪些情况会触发RDB快照
- 配置文件中默认的快照配置
- 手动save/bgsave命令
- 执行flushall/flushdb命令也会产生dump.rdb文件,但里面是空白。
- 执行shutdown,且没有开启AOF持久化
- 主从复制比时,主节点自动触发
1.8 禁用快照
修改配置
save ""
命令修改
redis-cli config set save ""
1.9 RDB优化配置项
# yes(默认, 推荐)
# no: 表示不在户数据不一致or其他手段发现和控制这种不一致,那么在快照写入失败时,也能确保redis继续接受新的写请求。
stop-writes-on-bgsave-error yes# yes(默认, 推荐): 对于存储到磁盘中的快照,可以设置是否进行压缩存储。
# 如果是:redis则会采用LZF算法进行压缩。
rdbcompression yes# yes(默认, 推荐): 在存储快照后,还可以让redis使用CRC64算法进行数据校验,但是这样做会增大10%的性能消耗,如果希望性能最大提升,则可以关闭。
rdbchechsum yes# 在没有持久性的情况下删除复制中使用的RDB文件启动
# 默认为no
rdb-del-sync-files no
2 AOF(Append only file)持久化
2.1 AOF介绍
定义:以日志的形式来记录每个写操作,将Redis执行过得所有写指令记录下来(读操作不记录),只许追加文件不可以写文件,redis启动之初会读取该文件重新构建数据,换言之,reids重启的话就根据日志文件的内容将写指令从前到后执行一次,以完成数据的恢复工作。
默认情况下,redis没有开启AOF。
保存文件为:appendonly.aof
2.2 AOF持久化工作流程
- Client作为命令的来源,会有多个源头以及源源不断的请求命令。
- 在这些命令到达Redis Server以后,并不是直接写入AOF文件,而是会将这些玩命令先放入到AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域,存在的目的是当这些命令到达一定量以后再写入磁盘,避免频繁的IO操作。
- AOF缓冲区会根据AOF缓冲区同步文件的三种写会策略,将命令写入磁盘上的AOF文件。
- 随着写入AOF内容的增加,为避免文件膨胀,会根据规则进行命令合并(又称AOF重写),从而起到AOF文件压缩的目的。
- 当Redis Server服务器重启的时候,就会从AOF文件载入数据。
2.3 AOF的三种写回策略
Always
:同步回写,每个命令执行完立刻同步地将日志写会磁盘。
everysec
:每秒写回,每个命令执行完,只是先把日志写到AOF文件的内存缓冲区,每隔1s把缓冲区的内容写入磁盘。
no
:操作系统控制写回,每隔命令执行完,只是先把日志写到AOF文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘。
# 1379
appendonly everysec
配置项 | 写回时机 | 优点 | 缺点 |
---|---|---|---|
Always | 同步写回 | 可靠性高,数据基本不丢失 | 每个写命令都要落盘,性能影响大 |
Everysec | 每秒写回 | 性能适中 | 宕机时丢失1s内的数据 |
No | 操作系统控制写回 | 性能好 | 宕机时丢失的数据较多 |
2.4 配置文件
在redis6中只用单个AOF文件,但是在redis7中,AOF被拆分为了3个文件(Multi Part AOF设计)
- base:一般由子进程通过重写产生,该文件最多只有一个。
- incr:一般会再AOFRW开始执行时被创建爱,每次AOFRW成功完成时,本次AOFRW之前对应的BASE和INCR AOF,都将变为HISTORY,HISTORY类型的AOF会被Redis自动删除。
- history
redis6
# AOF开启
appendonly yes# 写回策略
appendfsync everysec# 保存路径 与RDB一样
dir /usr/local/redis/data# 文件名
appenddirname "appendonly.aof"
reids7
# AOF开启
appendonly yes# 写回策略
appendfsync everysec# RDB数据保存路径
dir /usr/local/redis/data# AOF保存路径(自动拼接dir)
# 1412 {dir}/appendonlydir
appenddirname "appendonlydir"# 1406 文件名
appenddirname "appendonly.aof"
Append only mode模块
# 是否开启aof
appendonly yes# 文件名称
appendfilename "appendonly.aof"# 同步方式: everysec/always/no
appendfsync "everysec"# aof重写期间是否同步
no-appendfsync-on-wirte no# 重写触发配置、文件重写策略
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
2.5 AOF文件修复
问题:AOF文件没有写完,宕机等情况
异常修复命令
redis-check-aof --fix ***.aof
2.6 优缺点
优点
- 更好的保护数据不丢失、性能高、可做紧急恢复
缺点
- 就相同数据集的数据而言,AOF文件要远大于rdb文件,回复速度慢于rdb
- aof运行效率要慢于rdb,每秒同步策略效率要好。
2.7 AOF重写
- 在重写开始前,redis会创建一个"重写子进程",这个子进程会读取现有的AOF文件,并将其包含的指令进行分析压缩写入到一个临时文件中。
- 与此同时,主进程会将新收到的指令一遍积累到内存缓冲区中,一遍继续写入原有的AOF文件中,这样做是保证原有的AOF文件的可用性,避免在重写的过程中出现意外。
- 当“重写子进程”,完成重写工作后,它会给父进程发一个信号,父进程收到信号后就会将内存中的写指令追加到新AOF中
- 当追加结束后,redis就会用新AOF文件来替换旧AOF文件,之后再有新的指令,就会追加到新的AOF文件中。
- 重写AOF文件的操作,并没有读取旧的AOF文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。
3 RDB-AOF混合持久化
默认在同时开启rdb和aof持久化时,重启时只会加载aof文件,不会加载rdb文件。
开启混合持久化方式后:
- RDB快照做全量持久化
- AOF做增量持久化
配置
# 开启混合持久化配置
aof-use-rdb-preamble yes
先使用RDB进行快照存储,然后使用AOF持久化记录所有的写操作,当重写策略满足或者手动触发重写的时候,将最新的数据存储为RDB记录。这样的话重启服务的时候会从RDB何AOF两部分恢复数据,既保证了数据完整性,又提高了恢复数据的性能。
4 纯缓存模式(同时关闭RDB+AOF)
# 禁用RDB
# 禁用后仍然可以使用save、bgsave生成RDB文件
save ""# 禁用AOF
# 禁用后,仍然可以使用 bgrewrtteaof 生成aof文件
appendonly no
参考地址:
(尚硅谷~阳哥)
更多推荐
Redis(三) 持久化 RDB+AOF
发布评论