1.1 RDB(Redis DataBase)
RDB(Redis 数据库):RDB 持久性以指定的时间间隔执行数据集的时间点快照。
- 在指定的时间间隔,执行数据集的时间点快照
- 实现类似照片记录效果的方式,就是把某一时刻的数据和状态以文件的形式写到磁盘上,也就是快照。这样一来即使故障宕机,快照文件也不会丢失,数据的可靠性也就得到了保证。
- 这个快照文件就称为RDB文件(dump.rdb),其中,RDB就是Redis DataBase的缩写。
- 将内存数据全部保存到磁盘dump.rdb文加中
Redis6的时候
Redis7之后的变化频率
save 3600 1 300 100 60 100 // 3600秒 修改一次 100秒 修改60次 60秒 修改10000次 触发保存
修改配置
修改dump文件保存地址,默认在配置文件
修改dump文件名称
自动触发
第一种情况
修改达到次数 自动生成
第二种情况
修改一次后,超过时间,在修改
恢复备份自动操作
执行flushall/flushdb/shutdown命令也会产生dump.rdb文件,但里面是空的,无意义
物理恢复,一定服务和备份分机隔离,各自存储
手动触发
Save
- 在主线程中执行会阻塞redis服务器,直到持久化工作完成才能处理其他命令, 线上禁止使用
BGSAVE(默认)
-
Redis 会在后台异步进行快照操作,不阻塞快照同时还可以响应客户端请求,该触发过程会 fork 一个子进程由子进程复制持久化过程
-
lastsave 命令可以获取最后一次成功执行快照的时间
使用date -d @+用lastsave得到的时间戳 转换成当前时间
-
Redis会使用bgsave对当前内存中所有数据做快照,这个操作是子进程在后台完成的,这就允许主进程同时可以修改
fork是什么
克隆 不影响当前主进程
在Linux程序中,fork ()会产生一个和父进程完全相同的子进程,但子进程后多会exec系统调用,出于效率考虑,尽量避免膨胀。
save
bgsave
RDB的优缺点
优点:
- 适合大规模的数据恢复
- 按照业务定时备份
- 对数据完整性和一致性要求不高
- RDB 文件在内存中的加载速度比AOF快得多
缺点:
- 在一定间隔时间做一次备份,如果redis意外down机,就会丢掉最近一次快照到down机时的数据
- 内存数量的全量同步,如果数据量过大会导致IO严重影响服务器性能
- RDB依赖于主进程的 fork ,在更大的数据集中,这可能会导致服务器请求的瞬间延迟
- fork 的时候内存中的数据被克隆了一份,大致2倍的膨胀性,需要考虑
如何检查修复dump.rdp文件
修复: redis-check-rdb 文件名
哪些情况会触发RDB快照
- 配置文件中默认的快照配置
- 手动 save/bgsave 命令
- 执行flush / flushdb 命令也会产生 dump.rdb 文件,但里面是空的,无意义
- 执行 shutdown 且没有设置开启 AOF 持久化
- 主从复制时,主节点自动触发
如何禁用RDB快照
1.动态所有停止 RDB 保存规则的方法: redis -cli config set save “”
2.配置文件
RDB其余配置优化
总结
1.2 AOF
- 以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
- 默认情况下,redis是没有开启AOF的
- 开启AOF 功能需要设置配置 : appendonly yes
- AOF保存的是appendonly.aof文件
AOF持久化工作流程
AOF缓冲区的三种写回策略
- always 同步写回,每个写命令执行完立刻同步地将日志写回磁盘,会造成大量的IO
- everysec 每秒写回,每个写命令执行完,只是先把日志写到AOF缓冲区,每隔1s把缓存区地数据写入磁盘
- no,操作系统控制协会,只是将日志先写到AOF文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘,会丢命令
三种策略的小总结
AOF 相对于Redis6 Redis7有何变化
底层的变了
AOF配置、启动、修复、恢复
AOF的配置
开启AOF
AOF-- 保存路径
AOF文件 --保存名称
redis6只有一个文件
Redis7之后有三个文件
Redis7 config对应的配置项
AOF的正常恢复
AOF的异常恢复
错误的AOF文件,会导致redis启动不了
在网络闪断时,aof文件写了错误的指令,使用
异常修复命令 : redis-check-aof --fix 进行修复
AOF的优缺点
优点:
- 更好的保护数据不丢失、性能高、可做紧急恢复
缺点:
- 相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb
- aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同
AOF的重写机制
1.什么是AOF的重写机制
一句话总结:启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集
由于AOF持久化是Redis不断将写命令记录到AOF文件中,随着Redis不断的进行,AOF的文件会越来越大,文件越大,占用服务器内存越大以及AOF恢复要求时间越长。
为了解决这个问题,Redis新增了重写机制,当AOF文件的大小超过所设定的峰值时,Redis就会自动启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集
或者
可以手动使用命令bgrewriteaof来重新。
2.触发机制
开启重写
自动触发
- 满足配置文件中的选项后,Redis会记录上次重写时地AOF大小
- 默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时
手动触发
- 客户端向服务器发送 bgrewriteaof 命令
也就是一旦重写就会生成新的base、incr文件,去替换之前的
3.结论
也就是说AOF文件重写并不是对原文件进行重新整理,而是直接读取服务器现有的键值对,然后用一条命令去代替之前记录这个键值对的多条命令,生成一个新的文件后去替换原来的AOF 文件。
AOF文件重写触发机制: 通过redis.conf 配置文件中的auto-aof-rewrite-percentage:默认值为100,以及auto-aof-rewrite-min-size: 64mb配置,也就是说默认Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
4.重写原理
- 在重写开始前,redis会创建一个“重写子进程”,这个子进程会读取现有的AOF文件,并将其包含的指令进行分析压缩并写入到一个临时文件中。
- 与此同时,主进程会将新接收到的写指令一边累积到内存缓冲区中,一边继续写入到原有的AOF文件中,这样做是保证原有的AOF文件的可用性,避免在重写过程中出现意外。
- 当“重写子进程”完成重写工作后,它会给父进程发一个信号,父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
- 当追加结束后,redis就会用新AOF文件来代替旧AOF文件,之后再有新的写指令,就都会追加到新的AOF文件中
- 重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似
AOF优化配置项
总结
1.3 RDB+AOF混合持久化
共存听AOF的
数据恢复顺序和加载流程
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
同时开启两种持久化方式
- 当redis 重启时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
- RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件
- 那要不要只使用AOF呢
- 安特雷兹建议不要
- 因为RDB更适合用于备份数据库(AOF不断变化不好备份),留着AOF作为一个万一的手段
- 那要不要只使用AOF呢
1.4 纯缓存模式
同时关闭RDB + AOF
- save “”
- 禁用rdb
- 禁用db持久化模式下,我们仍然可以使用命令save、bgsave生成rdb文件
- appendonly no
- 禁用aof
- 禁用aof持久化模式下,我们仍然可以使用命令 bgrewriteaof生成aof文件