redis持久化

最新推荐文章于 2024-05-23 00:07:30 发布

山海自有归期

最新推荐文章于 2024-05-23 00:07:30 发布

阅读量403

点赞数

分类专栏：数据库文章标签： redis 数据库缓存

本文链接：https://blog.csdn.net/weixin_50691399/article/details/122087997

版权

数据库专栏收录该内容

34 篇文章 0 订阅

订阅专栏

2：自动：按照配置文件中的条件满足就执行BGSAVE

3：手动：客户端发起SAVE、BGSAVE命令手动关闭service会触发

五：AOF（AppendOnlyFile）

一：什么是持久化

将数据从掉电易失的内存存放到能够永久存储的设备上（异常关闭或者杀死数据存储在cipan下次打开会从磁盘读取数据）

二：Redis为什么需要持久化

基于内存的

缓存服务器，需要吗？不需要

内存数据库，需要吗？需要

三：Redis持久化方式

RDB（Redis DB）

AOF（AppendOnlyFile）

四：RDB（Redis DB）

1：RDB概念

在默认情况下，Redis 将数据库快照（相当于备份）保存在名字为 dump.rdb的二进制文件中

策略

2：自动：按照配置文件中的条件满足就执行BGSAVE

（1：save 60 1000，Redis要满足在60秒内至少有1000个键被改动，会自动保存一次

save 900 1 900秒内一条

save 300 10 300秒内10条

save 60 10000 60秒内10000条

会触发rdb自动机制。

杀死服务，数据不会保存到磁盘造成数据丢失无法确定丢失的数据量。

3：手动：客户端发起SAVE、BGSAVE命令手动关闭service会触发

（1：SAVE命令

redis > save

阻塞Redis服务，无法响应客户端请求

创建新的dump.rdb替代旧文件

redis一次只能执行一个命令所以执行save命令会堵住管道，客户机向服务器发送请求。

（2：BGSAVE命令BGSAVE是一个异步命令

redis > bgsave

非阻塞，Redis服务正常接收处理客户端请求

Redis会folk()一个新的子进程来创建RDB文件，子进程处理完后会向父进程发送一个信号，通知它处理完毕

父进程用新的dump.rdb替代旧文件

如果发生的是bgsave会在原本的管道上开辟一个子进程来执行其他的命令

（3：SAVE 和 BGSAVE 命令

SAVE不用创建新的进程，速度略快

BGSAVE需要创建子进程，消耗额外的内存

SAVE适合停机维护，服务低谷时段

BGSAVE适合线上执行

4：自动执行

本质上就是BGSAVE

默认配置

save 900 1

save 300 10

save 60 10000

dbfilename dump.rdb

dir /var/lib/redis/6379

只要上面三个条件满足一个，就自动执行备份。

创建RDB文件之后，时间计数器和次数计数器会清零。所以多个条件的效果不是叠加的

5：优点

完全备份，不同时间的数据集备份可以做到多版本恢复（对产生的.rdb文件及时修改文件名）

紧凑的单一文件，方便网络传输，适合灾难恢复（备份数据恢复）异地容灾（把备份保存在另一台机器）

恢复大数据集速度较AOF快

6：缺点

会丢失最近写入、修改的而未能持久化的数据（新文件会覆盖旧文件）

folk过程非常耗时，会造成毫秒级不能响应客户端请求

7：生产环境

创建一个定时任务cron job，每小时或者每天将dump.rdb复制到指定目录

确保备份文件名称带有日期时间信息，便于管理和还原对应的时间点的快照版本

定时任务删除过期的备份

如果有必要，跨物理主机、跨机架、异地备份

五：AOF（AppendOnlyFile）

1：基本概念

Append only file，采用追加的方式保存在配置文件/bin/redis.conf 文件中Appendly设置为yes

默认文件appendonly.aof

记录所有的写操作命令，在服务启动的时候使用这些命令就可以还原数据库

将完整的命令保存到.aof文件中

2：调整AOF持久化策略

可以在服务出现故障时，不丢失任何数据，也可以丢失一秒的数据。相对于RDB损失小得多

3：AOF写入机制

AOF方式不能保证绝对不丢失数据

目前常见的操作系统中，执行系统调用write函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区（buffer）里面，等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失

3：写入磁盘的策略

appendfsync选项，这个选项的值可以是always、everysec或者no

Always：服务器每写入一个命令，就调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据（最多丢一个命令或者不会丢，不会丢任何数据）。不采用是因为每次都要写入磁盘，比较慢

Everysec（默认）：服务器每一秒重调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据

No：服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的

运行速度：always的速度慢，everysec和no都很快

关闭服务再次打开会读adf文件将命令重新执行，命令会抵消叫重写机制

4：AOF重写机制

AOF文件过大（不仅有数据还有命令）例如：set a 然后又del a也会保存重启时还是会重新执行

合并重复的操作，AOF会使用尽可能少的命令来记录（合并重复的操作）

重写过程

folk一个子进程负责重写AOF文件

子进程会创建一个临时文件写入AOF信息

父进程会开辟一个内存缓冲区接收新的写命令（边写边接收）

子进程重写完成后，父进程会获得一个信号，将父进程接收到的新的写操作由子进程写入到临时文件中

新文件替代旧文件

注：如果写入操作的时候出现故障导致命令写半截，可以使用redis-check-aof工具修复

重写可以把一个很大的文件压缩

5：AOF重写触发

手动：客户端向服务器发送BGREWRITEAOF命令（重写文件会变小）

自动：配置文件中的选项，自动执行BGREWRITEAOF命令

auto-aof-rewrite-min-size ，触发AOF重写所需的最小体积：只要在AOF文件的体积大于等于size时，才会考虑是否需要进行AOF重写，这个选项用于避免对体积过小的AOF文件进行重写

auto-aof-rewrite-percentage ，指定触发重写所需的AOF文件体积百分比：当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积（默认是64mb），并且超过上一次重写之后的AOF文件体积的percent %（100%）时，就会触发AOF重写。（如果服务器刚刚启动不久，还没有进行过AOF重写，那么使用服务器启动时载入的AOF文件的体积来作为基准值）。将这个值设置为0表示关闭自动AOF重写