Redis04持久化操作

Redis持久化操作

0、总体介绍

• 为了防止服务器宕机导致Redis数据缓存丢失，所以我们需要数据持久化。

• Redis数据库提供了两种不同形式的持久化方式。
  • RDB（Redis DataBase）
  • AOF（Append Of File）

具体原理图：

1、RDB（Redis DataBase）

1.1、官网介绍

1.2、是什么

• 在指定时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，他恢复时是将快照文件直接读取到内存内。

1.3、备份是如何执行的

• Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中主进程是不行进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。
• RDB的缺点是最后一次持久化后的数据可能丢失（因为他并不是实时进行更新的，而是有时间间隔的）。

1.4、Fork

• Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
• 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，单子进程会调用exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”。
• 一般情况下父进程和子进程会同用同一段物理内存，只有进程空间的各段的内容发生变化时，才会将父进程的内容复制一份给子进程。

1.5、案例演示

1.5.1、需求说明

1.5.2、配置文件（6 VS 7）

1. Redis6.0.16以下

2. Redis6.2以及Redis7

1.5.3、操作步骤

自动触发：

操作流程：

1. 修改保存频率

2. 修改dump文件保存路径（写的路径一定要保证存在）

• 自定义修改的路径可以进入redis里用CONFIG GET dir获取目录。

测试：

3. 修改dump文件名称

4. 触发备份

**第一次测试：**5秒内加入两次数据触发保存

**第二次测试：**5秒内只加入一次数据未触发保存

**第三次测试：**5秒内再加入两次数据触发保存

---

手动触发：save 和 bgsave

Redis提供了两个命令来生成RDB文件，分别是save和bgsave。

1. save

• 在主程序中执行会阻塞当前redis服务器，知道持久化工作完成。执行save命令期间，redis不能处理其他命令，线上禁止使用。

案例：

2. bgsave（默认）

• Redis会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，该触发方式会fork一个子进程由子进程复制持久化过程。

官网说明：

• Redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据。

fork是什么？

案例：


LASTSAVE：可以通过lastsave命令获取最后一次成功执行快照的时间
案例：

1.6、优势

官网说明：


小总结：

• 适合大规模的数据恢复
• 按照业务定时备份
• 对数据完整性和一致性要求不高
• RDB文件在内存中的加载速度要比AOF快得多

1.7、劣势

官网介绍：


小总结：

• 在一定时间间隔做一次备份，所以如果Redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失。
• 内存数据的全量同步，如果数据量太大会导致I/O严重影响服务器性能。
• RDB依赖于主进程的fork，在更大娥数据集中，这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑。

数据丢失案例：

1. 正常录入数据
2. kill -9 模拟意外down机
3. redis重启恢复，查看数据是否丢失

1.8、如何检查修复dump.rdb文件

通过此命令进行修复：

修复案例：

1.9、哪些情况会触发RDB快照

1. 配置文件中默认的快照配置
2. 手动save/bgsave命令
3. 执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义
4. 执行shutdown且没有设置开启AOF持久化
5. 主从复制时，主节点自动触发

1.10、如何禁用快照

1. 动态所有停止RDB保存规则的方法：redis-cli config set save “”.
2. 快照禁用

1.11、RDB优化配置项详解

• 配置文件SNAPSHOTTING模块

save

dbfilename

dir

stop-writes-on-bgsave-error

rebcompression

rebchecksum

rdb-del-sync-files

1.12、小总结

2、AOF（Append Only File）

2.1、官网介绍

2.2、是什么

• 以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
• 默认情况下，redis是没有开启AOF（append Only File）的。
• 开启AOF功能需要设置配置：appendonly yes。

2.3、能干嘛

• AOF保存的是appendonly.aof文件。

2.4、AOF持久化工作流程

2.5、AOF缓冲区三种写回策略

Always

• 同步写回，每个写命令执行完立刻同步地将日志写回磁盘

everysec

• 每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区的内容写入磁盘。

no

• 操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定合适将缓冲区的内容写回磁盘。

小总结

2.6、AOF配置/启动/修复/恢复

配置文件说明（6VS7）

如何开启AOF：

使用默认写回策略，每秒钟：

aof文件-保存路径：
redis6：

• AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的dir配置
• 官方：

redis7之后更新：

• 最终路径：dir+appenddirname

aof文件-保存名称：https://blog.csdn.net/happytree001/article/details/123450432
redis6：有且只有一个

Redis7 Multi Part AOF的设计：

1. 官网说明

2. 从1到3

• base基本文件
• incr增量文件
• manifest清单文件

3. Redis7.0config中对应的配置项

正常恢复

• 启动：设置yes（修改默认的appendonly no，改为yes）
• 写操作继续，生成aof文件到指定的目录
• 恢复1：重启redis然后重新加载，结果OK（正常恢复）

异常恢复

1. 故意乱写正常的aof文件，模拟网络闪断文件写error。
2. 重启redis之后就会进行aof文件的载入，发现启动都不行~~~
3. 异常修复命令：redis-check-aof --fix 进行修复
4. 重新启动OK

生成aof文件：

恶意修改aof文件：

重启：发现aof文件错误会导致redis无法正常启动

修复aof文件：



重启redis：（修复完成）

2.7、优势

• 更好的保护数据不丢失、性能高、可做紧急恢复。

2.8、劣势

• 相同数据集的数据而言aof文件远大于rdb文件，恢复速度慢于rdb
• aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

2.9、AOF重写机制（重点）

是什么

一句话：启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

• 由于AOF持久化是Redis不断将写命令记录到AOF文件中，随着Redis不断地进行，AOF文件会越来越大，文件越大，占用服务器内存越大以及AOF恢复要求时间越长。
• 为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
• 或者可以手动使用命令bgrewriteaof来重写。

触发机制

官网默认配置：

自动触发：

• 满足配置文件中的选项后，redis会记录上次重写时的AOF文件大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时。

手动触发：

• 客户端向服务器发送bgrewriteaof命令

案例证明

需求说明：

需求验证：

• 启动aof文件的内容压缩，只保留可以恢复数据的最小指令集。

步骤：
前期准备：

1. 开启aof

2. 重写峰值修改为1k

3. 关闭混合，设置为no

4. 删除之前的全部aof和rdb文件，清除干扰项。

自动触发案例：

1. 完成上述正确配置，重启redis服务器，执行set k1 v1查看aof文件是否正常

2. 查看三大配置文件

3. k1不停111111暴涨

手动触发案例：

小结论：

重写触发

1. 在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的aof文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
2. 与此同时，主进程会将新接收到的写指令一边积累到内存缓冲区中，一边继续写入到原有的aof文件中，这样做是保证原有的aof文件的可用性，避免在重写过程中发生意外。
3. 当“重写子进程”完成重写工作后，他会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新aof文件中。
4. 当追加结束后，redis就会用新的aof文件来代替旧的aof文件，之后再有新的写指令，就都会追加到新的aof文件中。
5. 重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有些类似。

2.10、AOF优化配置项详解

• 配置文件APPEND ONLY MODE模块

2.11、小总结

3、RDB和AOF混合持久化

3.1、官网建议

3.2、rdb vs aof

官方

数据恢复顺序和加载流程

• appendonly.aof+dump.rdb，优先使用appendonly.aof去恢复数据，但是我们发现redis自动生成的appendonly.aof是没有数据的然后我们自己的dump.rdb是有数据的，但是明显没用我们的数据。很简单，就是虽然你删除了appendonly.aof，但是因为打开了aof持久化，redis就一定会优先基于aof去恢复，即使文件不在，那就创建一个新的空的aof文件。
• 在数据安全丢失的情况下，基于rdb冷备，如何完美的恢复数据，同时还保持aof和rdb的双开？
• 停止redis，关闭aof，拷贝rdb备份，重启redis，确认数据恢复，直接在命令行热修改redis配置，打开aof，这个redis就会将内存中的数据对应的日志，写入aof文件中，此时aof和rdb两份数据文件的数据就同步了。

3.3、怎么选？用哪个？

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
• 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表示禁用。

• 当只开启aof持久化，而不设置aof-use-rdb-preamble时，rdb不会被服务器读取，也就是rdb不会生效。

2. RDB+AOF的混合模式------->结论：RDB镜像做全量持久化，AOF做增量持久化

先试用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，即保证了数据的完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。=====>AOF包括了RDB头部和AOF混写。

4、纯缓存模式

• 同时关闭RDB和AOF

4.1、关闭RDB

• save ""：禁用rdb
• 禁用rdb持久化模式下，我们仍然可以使用save，bgsave生成rdb文件。

4.2、关闭AOF

• appendonly no：禁用aof
• 禁用aof持久化模式下，我们仍然可以使用命令bgrewriteaof生成aof文件