Redis持久化以及数据备份和恢复

最新推荐文章于 2024-07-31 15:51:55 发布

崩玉~雅

最新推荐文章于 2024-07-31 15:51:55 发布

阅读量225

点赞数

分类专栏： Redis

本文链接：https://blog.youkuaiyun.com/qq_41961316/article/details/103495643

版权

Redis 专栏收录该内容

4 篇文章

订阅专栏

本文深入探讨Redis的RDB和AOF两种持久化机制，包括它们的工作原理、优缺点及配置策略。RDB适合冷备份，而AOF能更好地保护数据，两者结合使用可提升数据安全性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1.持久化的意义

灾难恢复，数据恢复。可以归类到类似高可用的环节；如果redis挂了，重启redis，从磁盘上读取数据到内存中

2.RDB和AOF两种持久化机制

RDB，12：00，redis中有100条数据，生成RDB文件，有100条数据

12：05 ，redis中有150条数据，生成RDB文件，有150条

周期性的，生成一份完整的快照。

AOF，每次redis中写入一条数据，先写到 os cache中，再写入磁盘文件 AOF文件。redis每隔固定时间，调用系统fsync,

强制将cache中的数据刷入磁盘文件中。对每条写入命令作为日志，以append-only模式写入日志文件中。可以通过回放aof日志中的写入指令来重构整个数据集

redis中数据有一定限量，aof不能无限增长，redis中的数据到达一定数量时，采用缓存淘汰算法，LRU（最不经常使用）.，自动将一部分数据从内存中清除。当aof大到一定时候，AOF做rewrite（重写）操作（基于当时内存中的数据，构造更小的AOF文件，删除旧AOF文件）。可能存在一种情况，redis中50w数据（淘汰过后），aof100万，此时重写aof，aof数据量变小。aof的一定程度？

如果同时使用2中机制，redis会使用AOF重构数据

3.RDB持久化机制的优点

（1）RDB会生成多个数据文件（全量快照），每个文件代表某一个时刻中redis的数据。非常适合做冷备份，可以将完整数据发送到远程安全存储上。 AOF 冷备份，需要借助脚本

（2）RDB 对redis 对外提供的读写服务，影响非常小，可以让redis保持高性能，redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作进行持久化。

RDB每次写，都是写redis内存，周期性IO

AOF，每次都要写文件，

（3）相对于AOF，RDB数据文件启功和恢复redis进程更快；AOF存放的指令日志，做数据恢复时候，需要回放和执行所有指令日志。RDB 就是一份数据文件，恢复时直接加载到内存中

4.RDB持久化缺点

（1）可能存在丢失数据问题，周期性备份，会失去最近周期的数据

（2）生成数据文件过大时，可能会导致对客户端提供服务暂停数毫秒，甚至秒。一般不要让RDB的间隔太长

5.AOF持久化机制

（1）可以更好的保护数据不丢失，一般AOF每隔一秒，通过后台线程执行一次fsync操作，最多丢失1秒的数据

（2）AOF日志文件以append-only模式写入，没有磁盘寻址开销，写入性能非常高，文件不易破损，即使文件尾部破损，也容易恢复

（3）后台重写，不影响客户端的读写。在创建新的日志文件时，老的日志文件照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可

（4）AOF日志文件的命令通过非常可读的方式进行记录。可以通过拷贝AOF文件（未重写），将部分命令删除，再将AOF放回去，恢复文件。

6.AOF缺点

（1）对于同一份数据，aof日志文件通常比RDB快照文件更大

（2）aof的写qps比RDB的写qps低，aof一般配置成每秒fsync一次日志文件

（3）数据恢复的时候比较慢，做冷备份，定期备份不方便

7.RDB持久化配置

redis.conf文件中，配置持久化（默认开启）

save 60 1000, 每隔60s，如果超过1000个key发生了变更，就生成一个新的dump.rdb文件。snapshotting(检查点）

可以设置多个检查点。

也可以手动调用save 或bgsave命令，同步或异步执行rdb快照生成

RDB持久化机制工作流程：

（1）redis根据配置，尝试生成rdb快照文件

（2）fork一个子进程出来

（3）子进程尝试将数据dump到临时的rdb快照文件中

（4）rdb文件生成后，替换旧的快照。每次生成新的快照，都会覆盖之前的老快照

RDB数据恢复测试流程

（1）设置几个key，通过 redis-cli shutdown 方式停止redis服务，该方式是redis安全退出的模式，redis会将内存中（并非追加）的数据立即生成一份完整的rdb快照。通过cat dump.rdb可查看，该文件位置可在 redis.conf中 dir 向配置，默认 ./。

（2）kill -9 方式杀死redis进程，redis可能会丢失数据

（3）手动设置几个save检查点，写入几条数据，杀死进程看rdb文件是否存在数据。

redis 启动命令：reids-server redis.config (一定要带上redis.conf,否则新配置的文件不生效）

8 AOF持久化配置

默认关闭，打开： appendonly yes 。在生产环境，默认要打开aof

可以配置aof的fsync策略，有3种，每次写入一条数据就执行fsync,每隔一秒执行fsync,不主动执行fsync

appendfsync always: 每次写入一条数据就执行fsync，性能低

appendfsync everysec:每秒将 os cache 中的数据fsync到磁盘，常用，生产用，可以上万QPS

appendfsync no: 由操作系统策略写入磁盘，不可控

redis重启，优先使用 aof文件恢复。

aof自动重写策略：auto-aof-rewrite-percentage 100, 增长百分比（相对上次的aof文件大小）阈值，超过则进程重写

auto-aof-rewrite-min-size 64mb ,上条规则执行的条件，aof文件最小64mb，超过触发上条规则

AOF重写流程

（1）redis fork 一个子进程

（2）子进程基于当前内存数据，创建一个新的aof日志文件

（3）客户端写入，将日志保存旧aof日志文件，同时在内存中写入日志

（4）子进程写完新日志文件后，redis主进程将内存中的新日志追加到新aof文件

（5）新的日志文件替换旧的日志文件

9数据恢复和备份思路

（1）RDB和AOF同时工作，同一时刻只允许一种工作机制进行备份

（2）如果dump.rdb 和aof文件同时存在，redis重启只会恢复aof中的文件。

停止redis，如果配置文件中开启了aof，即使aof文件不存在，redis自动创建aof文件，使用空的aof文件恢复，数据不存在。需要先关掉 aof ，重启redis才能恢复RDB文件中的数据。此时可以使用命令行，热修改redis配置aof（将数据刷入aof）。但是redis的配置文件没有被持久化修改。此时停止redis，开启aof，重启redis

命令： config get appendonly 查看aof开关

config set appendonly yes 开启aof

后台手动出发重写机制：bgrewriteaof （根据需要，当使用RDB快照进行恢复时，可以使用该命令，将生成一份基于内存的AOF文件）

备份思路：每小时将rdb文件备份一份，将48小时之前的rdb文件删除（小时级）

#!/bin/sh
cur_date=`date +%Y%m%d%k`
mkdir -p /opt/redis/rediscopy/$cur_date
cp /opt/redis/redis-3.2.1/data/* /opt/redis/rediscopy/$cur_date
towday_date=`date -d -48hour +%Y%m%d%k`
rm -rf /opt/redis/rediscopy/$towday_date