Redis持久化【学习笔记】

Redis持久化

官网地址： https://redis.io/docs/manual/persistence/

一.Reids RDB（Redis DataBase）

官网介绍：RDB（Redis 数据库）：RDB 持久性以指定的时间间隔执行数据集的时间点快照。

1.是什么

在指定的时间间隔，执行数据集的时间点快照
实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写道磁盘上，也就是快照，这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。
这个快照文件就称为RDB文件（dump.rdb）,其中，RDB就是Redis DataBase的缩写

2.能干嘛

1.在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot内存快照，它恢复时再将磁盘快照文件直接读回到内存里
2.Redis的数据都在内存中，保持备份时它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中，一锅端
3.Rdb保存的是dump.rdb文件

3.案例演示

1.需求说明：

2.配置文件(6 VS 7)
Redis6.0.16以下

Redis6.2以及Redis-7.0.0

操作步骤：
1.自动触发

• Rdis7版本，按照redis.conf里配置save

• 本次案例5秒2次修改

• 修改dump文件保存路径

• 修改dump文件名称

• 触发备份
  第一种情况：第二种情况：

• 如何恢复
  1.将备份文件(dump.rdb)移动到redis安装目录并启动服务即可
  2.备份成功后故意用flushdb情况redis，看看是否可以恢复数据
  3.结论：执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义
  

• 物理恢复，一定服务和备份分机隔离
  2.手动触发

save和bgsave

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

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

• BGSAVE(默认)

Redis会在后台异步进行快照操作，不阻塞
快照同时还可以响应客户端请求，该触发方式会fork一个子进程由子进程复制持久化过程
Redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据

fork是什么
在Linux程序中，fork（）会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，尽量避免膨胀

案例

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

4.优势

小总结：

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

5.劣势

小总结：

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

数据丢失案例

正常录入数据
kill -9 故意模拟意外宕机

redis重启恢复，查看数据是否丢失

6.如何检查修复dump.rdb文件

7.哪些情况会触发RDB快照

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

8.如何禁用快照

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

9.RDB优化配置项详解

配置文件SNAPSHOTTING模块

• save
• dbfilename
• dir
• stop-writes-on-bgsave-error
• rdbcompression
  
• rdbchecksum
• rdb-del-sync-files
  

10.小总结

二.AOF（Append Only File）

1.是什么

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

2.能干嘛

3.AOF保存的是appendonly.aof文件

4. AOF持久化工作流程

5.AOF缓冲区三种写回策略

三种写回策略

1. Always 同步写回，每个写命令执行完立刻同步将日志写回磁盘
2. everysec 每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓存区，每隔1秒把缓冲区中的内容写到磁盘
3. no 操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回数据

三种写回策略小总结update

6.案例演示和说明AOF配置/启动/修复/恢复

1. 配置文件说明

1. 如何开启aof
   
2. 使用默认写回策略，每秒钟
   
3. aof文件-保存路径

redis6 AOF保存文件的位置和RDB保存文件的位置一样
都是通过redis.conf配置文件的dir配置

redis7之后最新
最终路径

4. AOF文件-保存名称

redis6
有且仅有一个

Redis7.0 Multi Part AOF的设计
base基本文件
incr增量文件
manifest清单文件

Redis 7.0config 中对应的配置项

2.正常恢复：

启动：设置YES 修改默认的appendonly no 改为yes
写操作继续，生成aof文件到指定的目录

恢复1：重启redis然后重新加载，结果OK

恢复2：
写入数据进redis，然后flushdb+shutdown服务器
新生成了dump和aof
备份新生成的aof.bak，然后删除dump/aof再看恢复

重启redis然后重新加载试试？？？

停止服务器，拿出我们的备份修改后再重新启动服务器看看

3.异常恢复

故意乱写正常的AOF文件，模拟网络闪断文件写error

重启Redis之后就会进行AOF文件的载入，发现启动都不行

异常修复命令： redis-check-aof --fix 进行修复

重新OK

7.优势

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

8.劣势

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

9.AOF重写机制

1.是什么

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

2.触发机制

• 自动触发

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

• 手动触发

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

3.案例说明

需求说明：

启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
举例子：比如有个key
一开始你 set k1 v1
然后改成 set k1 v2
最后改成 set k1 v3
如果不重写，那么这3条语句都在aof文件中，内容占空间不说启动的时候都要执行一遍，共计3条命令；
但是，我们实际效果只需要set k1 v3这一条，所以，
开启重写后，只需要保存set k1 v3就可以了只需要保留最后一次修改值，相当于给aof文件瘦身减肥，性能更好。
AOF重写不仅降低了文件的占用空间，同时更小的AOF也可以更快地被Redis加载。

需求验证：

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

步骤：

• 前期配置准备：

开启aof

重写峰值修改为1k

关闭混合，设置为no

删除之前的全部aof和rdb，清除干扰项

• 自动触发案例01

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

查看三大配置文件

k1不停11111111暴涨

重写触发

• 手动触发案例02

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

结论：

4.重写原理

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

10.AOF优化配置项详解

配置文件APPEND ONLY MODE模块

11. 小总结

三.RDB-AOF混合持久化

1.rdb and aof

2.你怎么选？用哪个？

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重写执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾

3.同时开启两种持久化方式

在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始数据，因为在通常情况下AOF文件保存的数据要比RDB文件保存的数据集要完整
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者建议不要，应为RDB更适用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段

4.推荐方式

RDB+AOF混合方式

纯缓存模式

同时关闭RDB+AOF

save “”
禁用rdb
禁用rdb持久化模式下，我们仍然可以使用命令save，bgsave生成redb文件

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