1. 总体介绍
https://redis.io/docs/management/persistence/
官网
2. 持久化双雄 AOF, RDB
2.1 一图
2.2 RDB (Redis DataBase)
2.2.1 官网介绍
RDB（Redis 数据库）：RDB 持久性以指定的时间间隔执行数据集的时间点快照。
2.2.2 是什么
实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是
快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。
这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
2.2.3 能干嘛
1. 在指定的时间间隔内将内存中的数据集快照写入磁盘也就是行话讲的Snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里
2. 一锅端Redis的数据都在内存中，保存备份时它执行的是全量快照也就是说，把内存中的所有数据都记录到磁盘中，一锅端
3. Rdb保存的是dump.rdb文件
2.2.4 案例演示
1. 需求说明
2. 配置文件 6 VS 7
Redis6.0.16以下
Redis6.2以及Redis7.0
3. 操作步骤
3.1 自动触发
1) Redis7版本，按照redis,conf里配置的save <seconds> <changes>
2)本次案例5秒2次修改
3) 修改dump文件保存路径
4) 修改dump文件名称
5) 触发备份
6) 如何恢复
将备份文件(dump.rdb) 移动到 redis 安装目录并启动服务即可
备份成功后故意用flushdb清空redis，看看是否可以恢复数据 ,执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义
物理恢复，一定服务和备份分机隔离
备注：不可以把备份文件dump.rdb和生产redis服务器放在同一台机器，必须分开各自存储，
以防生产机物理损坏后备份文件也挂了。
3.2 手动触发 save和bgsave1) Redis提供了两个命今来生成RDB文件分别是save和bgsave
2) Save
~ 在主程序中执行会阻塞当前redis服务器，直到持久化工作完成执行save命令期间，Redis不能处理其他命令，线上禁止使用
~ 案例
3) BGSAVE(默认)
~ Redis会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求,该触发方式会fork一个了进程由子进程复制持久化过程
~ 官网说明
~ Redis会使用bgsave对当前内存中的所有数据做快照这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据。
~ fork是什么?
各位熟悉的
操作系统角度在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，尽量避免膨胀。
~ 案例
~ LASTSAVE
可以通过lastsave命令获取最后一次成功执行快照的时间
案例
2.2.5 优势
1. 官网说明
2. 小总结
1) 适合大规模的数据恢复
2) 按照业务定时备份
3) 对数据完整性和一致性要求不高
4) RDB 文件在内存中的加载速度要比 AOF 快得多
2.2.6 劣势
1. 官网说明
2. 小总结
1) 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失2) 内存数据的全量同步，如果数据量太大会导致I/0严重影响服务器性能
3) RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了-份，大致2倍的膨胀性，需要考虑
3. 数据丢失案例
1) 正常录入数据
2) kil!...9故意模拟意外宕机
3) redis重启恢复，查看数据是否丢失
2.2.7 如何检查修复dump.rdb文件
2.2.8 哪些情况会触发RDB快照
1. 配置文件中默认的快照配置
2. 手动save/bgsave命令
3. 执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义执行shutdown且没有设置开启AOF持久化4. 主从复制时，主节点自动触发
2.2.9 如何禁用快照
1. 动态所有停止RDB保存规则的方法: redis-cli config set save
2. 快照禁用
2.2.10 RDB优化配置项详解, 配置文件SNAPSHOTTING模块
1. save <seconds> <changes>
2. dbfilename
3. dir
4. stop-writes-on-bgsave-error
默认yes 如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的写请求5. rdbcompression
如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能6. rdbchecksum
7.rdb-del-sync-files
rdb-del-sync-files：在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。
2.2.11 小总结
2.3 AOF(Append Only File)
2.3.1 官网介绍
2.3.2 是什么
1. 以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
2. 默认情况下，redis是没有开启AOF(append only file)的开启AOF功能需要设置配置: appendonly yes
2.3.3 能干嘛
2.3.4 Aof保存的是appendonly.aof文件
2.3.5 AOF持久化工作流程
2.3.6 AOF缓冲区三种写回策略
1. 三种写回策略
1) Always
同步写回，每个写命令执行完立刻同步地将日志写回磁盘
2) everysec
每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘
3) no操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统
决定何时将缓冲区内容写回磁盘
2. 三种写回策略小总结update
2.3.7 案例演示和说明AOF配置/启动/修复/恢复
1. 配置文件说明(6 VS 7)
1) 如何开启aof
2) 使用默认写回策略，每秒钟
3) aof文件-保存路径~ redis6
AOF保存文件的位置和RDB保存文件的位置一样都是通过redis.conf配置文件的 dir 配置
官网文档
~ redis7之后最新
最终路径
dir + appenddirname
4) aof文件-保存名称
~ redis6
有且仅有一个
~ Redis7.0 Multi Part AOF的设计官网说明
从1到3, base基本文件 incr增量文件 maninfest清单文件
~ Redis7.0config 中对应的配置项
2. 正常恢复1）启动: 设置Yes修改默认的appendonly no，改为yes
2）写操作继续，生成aof文件到指定的目录
3）恢复1: 重启redis然后重新加载，结果OK
4）恢复2
~ 写入数据进redis，然后flushdb+shutdown服务器
~ 新生成了dump和aof
~ 备份新生成的aof.bak，然后删除dump/aof再看恢复
~ 重启redis然后重新加载试试? ? ?
~ 停止服务器，拿出我们的备份修改后再重新启动服务器看看
3. 异常恢复
1) 故意乱写正常的AOF文件模拟网终闪断文件写errorvim /myredis/appendonlydir/appendonly.aof.1.incr.aof
2) 重启 Redis 之后就会进行 AOF 文件的载入，发现启动都不行，o(T)o
3) 异常修复命令: redis-check-aof --fix 进行修复
redis-check-aof --fix 进行修复
4) 重新OK
2.3.8 优势
2.3.9 劣势
1. 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
2. aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同
2.3.10 AOF重写机制
1. 是什么
1）官网
由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，
文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。
为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，
只保留可以恢复数据的最小指令集
或者
可以手动使用命令 bgrewriteaof 来重新。
2）句话，启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
2. 触发机制
~ 官网默认配置
注意 ，同时满足，且的关系才会触发
1 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍
2 重写时满足的文件大小
~ 自动触发
满足配置文件中的选项后，Redis会记录上次重写时的AOF大小默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时
~ 手动触发
客户端向服务器发送bgrewriteaof命令
3. 案例说明1) 需求说明
2) 需求验证, 启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。3) 步骤
~ 前期配置准备开启aof
重写峰值修改为1k
关闭混合，设置为no
删除之前的全部aof和rdb，清除干扰项
~ 自动触发案例01完成上述正确配置，重启redis服务器执行set k1 v1查看aof文件是否正常
查看三大配置文件复习配置项
本次操作
k1不停1111111暴涨
重写触发
~ 手动触发案例02, 客户端向服务器发送bgrewriteaof命令
~ 结论
4. 重写原理4.1：在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
4.2：与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
4.3：当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
4.4：当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
4.5：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
2.3.11 AOF优化配置项详解
2.3.12 小总结
3. RDB,AOF混合持久化
3.1 官网建议
3.2 rdb vs aof
1. 问题
可否共存？如果共存听谁的？
2. 官网文档
3. 数据恢复顺序和加载流程
3.3 你怎么选? 用那个?
1. RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
2. AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
3.4 同时开启两种持久化方式推荐方式
在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢?
作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段.
3.5 RDB+AOF混合方式
结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据。
1 开启混合方式设置
设置aof-use-rdb-preamble的值为 yes yes表示开启，设置为no表示禁用
2 RDB+AOF的混合方式---------> 结论：RDB镜像做全量持久化，AOF做增量持久化
先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。----》AOF包括了RDB头部+AOF混写
4. 纯缓存模式，关闭RDB和AOF
4.1 save
禁用rdb
禁用rdb持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件
4.2 appendonly no
禁用aof
禁用aof持久化模式下，我们仍然可以使用命令bgrewriteaof生成aof文件
5310
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
