Redis ---3---持久化

Redis —3 ----持久化

​ 持久化就是把内存中的数据写入到磁盘里面

​

持化双雄

RDB（Redis DataBase）

​ RDB持久性以指定的时间间隔执行数据集的时间点快照（快照：实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。）这样以来，即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。

​ 这个快照文件就成为RDB文件（dump.rdb），其中，RDB就是Redis DataBase 的缩写。

​

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

​ Redis的数据都在内存中，保存备份时它执行的是全量快照，也就是硕，把内存中的所有数据都记录到磁盘中，一锅端。

案例演示

​

配置文件

​ Redis7之后

​

操作步骤

通过修改配置文件

自动触发

​ 本次案例每间隔5秒有2次修改

​ 配置文件内搜索Snapshotting，对其中的save进行修改

​

​ 修改dump文件保存路径 默认dir ./

​ 可以使用CONFIG GET dir获取目录

​ 修改为dir /myredis/dumpfiles

​ 修改dump文件名称

​

​ 可以使用 config set/get 属性来对配置文件进行修改

​ 触发备份

​ 如何恢复

​ 将备份文件（dump.rdb）移动到redis安装目录并启动服务即可

​ 执行flushall/flushdb命令、shutdown也会产生dump.rdb文件，但里面是空的，无意义

​ 物理回复，一定服务和备份分级隔离

备注：不可以把备份文件dump.rdb和生产redis服务器放在同一台机器，必须分开各自存储，以防生产机物理损坏后备份文件也挂了。redis重启时，会自动读取.rdb文件，来实现数据的读取。

手动触发

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

​ save

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

​ bgsave（默认）

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

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

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

​ lastsave

​ 可以通过lastsave命令获取最后一次成功执行快照的时间戳

​ 通过Linux端的date -d @ 指令来将时间戳转换为时间格式

​

RDB优点

​

​ 适合大规模的数据恢复

​ 按照业务定时备份

​ 对数据完整性和一致性要求不高

​ RDB文件在内存中的加载速度要比AOF快得多

RDB缺点

​ 在一定间隔时间做一次备份，所有如果redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失。

​ 内存数据的全量同步，如果数据量太大会导致I/O严重影响服务器性能。

​ RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。

​ fork的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑。（只有内存数据不一致的时候才会翻倍）

数据丢失案例

​ ①正常录入数据

​ ②kill -9 故意模拟意外down机

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

如何检查并修复.rdb文件

redis-check-rdb /目录/.rdb文件

哪些情况会触发RDB快照

​ 配置文件中默认的快照配置

​ 手动save/bgsave命令

​ 执行flushall、flushdb命令也会产生dump.rdb文件，但里面是空的

​ 执行shutdown且没有设置开启AOF持久化

​ 主从复制时，主节点自动触发

如何禁用快照

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

​ 修改配置文件 save “”

RDB优化配置项详解

​ 配置文件snapshotting模块

​ save

​ dbfilename 文件名称

​ dir 文件保存路径

​ stop -writes -on-bgsave-error

​ 默认为yes 如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的写请求。（建议yes）

​ sdbcompressiong

​ 默认为yes，对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。（建议yes）

​ rdbchecksum

​ 在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。（建议yes）

​ rdb-del-sunc-files

​ 在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。

小总结

AOF（Append only File）

是什么

​ 以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

​ 默认情况下，redis是没有开启AOF的。

​ 开启AOF功能需要设置配置：appendonly yes

AOF保存的是appendonly.aof文件

AOF持久化工作流程

AOF缓冲区三种写回策略

Always（永远）

​ 同步写回，每个写命令执行完立刻地将日志写回磁盘（频繁的I/O）

everysec（每隔一秒，默认）

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

no（不再）

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

​ 三种写回策略总结

案例演示和说明

​ AOF配置/启动/修复/恢复

如何开启AOF

设置三种写回策略（默认每秒）

AOF的保存路径

redis6

​ AOF保存文件的位置和RDB保存文件的位置------都是通过redis.conf配置文件的dir配置

redis7之后最新

​ appenddirname “appendonlydir”

AOF文件-保存名称

​ redis7.0之后

正常恢复：

​ 启动：设置Yes 修改默认的appendonly no，改为yes

​ 写操作继续，生成aof文件到指定的目录

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

​ 在对aof备份时使用cp指令，不能使用mv指令

​ 恢复2： 写入数据进redis，然后flushdb+shutdown服务器

​ 新生成了dump和aof

​ 备份新生成的aof.bak，然后删除dump/aof再看恢复

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

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

新增数据记录在.aof文件中

异常恢复：

​ 每一秒钟写入一次，如果内容才写了一小半，没有写完整，redis突然宕机，导致aof文件出错。

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

​ ②重启Redis之后就会进行AOF文件的载入，发现启动都不行，/(ㄒoㄒ)/~~

​ ③异常修复命令：redis-check-aof–fix进行修复 usr/local/bin目录下

Linux端

​ ④重新ok

redis端

优缺点分析：

AOF优势

​

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

AOF劣势

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb

aof运行效率要鳗鱼rdb，每秒同步策略效率较好，不同步效率和rdb相同

AOF重写机制案例

一句话

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

触发机制

​ 自动触发

​ 通过配置文件内容

​ auto-aof-rewrite-percentage 100

​ auto-aof-rewrite-min-size 64mb

​ 注意，同时满足，且的关系才会触发

​ 1，根据上次重写后的aof大小，判断当前aof大小是不是增长了一倍。

​ 2，重写时满足的文件大小。

​ 手动触发

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

案例说明

前期配置准备

​ ①开启aof

​ ②重写峰值修改为1k

​ ③关闭AOF+RDB混合模式，设置为no

​ aof-use-rdb-preamble no

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

自动触发案例01

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

​ ②查看三大配置文件

​ ③k1不停11111111暴涨

​ ④重写触发

手动触发案例

​ bgrewriteaof 直接手动触发，不管到没到达峰值

结论

重写原理

---

AOF小总结

RDB+AOF混合持久化

​ 数据恢复顺序和加载流程

​ 在同时开启rdb和aof持久化时，重启时只会加载aof文件，不会加载rdb文件

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

纯缓存模式

​ 同时关闭RDB和AOF

​ 关闭RDB：save “”

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

​ 关闭AOF：appendonly no

g-EmQhdRBx-1715781947734)]

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

[外链图片转存中…(img-H5Olhnw1-1715781947734)]

[外链图片转存中…(img-vZ8h0COS-1715781947735)]

[外链图片转存中…(img-sPhy697A-1715781947735)]

纯缓存模式

​ 同时关闭RDB和AOF

​ 关闭RDB：save “”

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

​ 关闭AOF：appendonly no

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