redis持久化:RDB:和AOF

目录

[RDB 持久化](#RDB 持久化)

1、修改配置文件:redis.conf

2、RDB模式自动触发保存快照

3、RDB模式手动触发保存快照

4、RDB的优缺点

AOF持久化

1、AOF持久化工作流程

2、修改配置文件开启AOF

3、AOF优缺点

4、AOF的重写机制原理

RDB+AOF混合模式


redis持久化有两种方式:RDB和AOF

RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot)。实现类似照片记录效果的方式,就是把某一时刻的数据和状态以文件的形式写到磁盘上,也就是快照。这样一来即使故障宕机,快照文件也不会丢失,数据的可靠性也就得到了保证。这个快照文件就称为RDB文件(dump.rdb),其中,RDB就是Redis DataBase的缩写。
AOF 持久化记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存,新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写(rewrite),使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。

Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下, 当 Redis 重启时, 它会优先使用 AOF 文件来还原数据集, 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。你甚至可以关闭持久化功能,让数据只在服务器运行时存在。

RDB 持久化

redis关于持久化配置文件的变化:

redis6.0.16以下

save 900 1:每隔900s(15min),如果有超过1个key 发生了变化,就写一份新的RDB文件

save 300 10:每隔300s(5min),如果有超过10 个key发生了变化,就写一份新的 RDB文件

save 60 10000:每隔60s(1min),如果有超过10000个key 发生了变化,就写一份新的RDB文件

redis6.2以上

save 3600 1:每隔3600s(1小时),如果有超过1个key 发生了变化,就写一份新的RDB文件

save 300 10:每隔300s(5min),如果有超过100个key发生了变化,就写一份新的 RDB文件

save 60 10000:每隔60s(1min),如果有超过10000个key 发生了变化,就写一份新的RDB文件

1、修改配置文件:redis.conf

快照文件名,建议加上端口号,多个redis容器好区分

2、RDB模式自动触发保存快照

修改保存时间:5秒中两次修改

重新启动容器

docker restart redis

进入容器查看是否配置成功

docker exec -it redis bash #进入容器

redis-cli #redis客户端

查看快照文件目录

/data# redis-cli -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) "123456"
127.0.0.1:6379> config get dir
1) "dir"
2) "/data"

测试:

测试前
[root@localhost data]# ll
总用量 4
-rw-------. 1 polkitd input 392 11月 21 21:49 dump.rdb


127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK

测试后
[root@localhost data]# ll
总用量 8
-rw-------. 1 polkitd input 107 11月 22 21:20 dump3679.rdb
-rw-------. 1 polkitd input 392 11月 21 21:49 dump.rdb

总结:5秒内修改2次或2次修改大于5秒都会触发,

redis重启就会读取快照恢复,执行flushall/flushdb命令也会产生dump.rdb文件,但里面是空的,无意义

3、 RDB模式手动触发保存快照

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

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

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

lastsave可以查看最后一次的时间戳

4、RDB的优缺点

RDB的优点

1、适合大规模的数据恢复

2、按照业务定时备份

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

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

RDB的缺点

1、在一定间隔时间做一次备份,所以如果redis意外宕机的话,就会丢失从当前至最近一次快照期间的数据,快照之间的数据会丢失

2、内存数据的全量同步,如果数据量太大会导致I/0严重影响服务器性能

3、RDB依赖于主进程的fork,在更大的数据集中,这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一俯,大致2倍的膨胀性,需要考虑

修复RDB文件

cd /usr/local/bin

进入bin目录找到:redis-check-rdb 命令,指定rdb文件

redis-check-rdb /usr/local/redis/data/dump6379.rdb

禁用RDB快照,把save前面的注释去掉,写个空字符串

RDB配置参数,使用默认即可

AOF持久化

默认情况下,redis是没有开启AOF(append only file)的。

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

1、AOF持久化工作流程

1、Client作为命令的来源,会有多个源头以及源源不断的请求命令。

2、在这些命令到达Redis Server 以后并不是直接写入AOF文件,会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域,存在的目的是当这些命令达到一定量以后再写入磁盘,避免频繁的磁盘IO操作。

3、AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件。

4、随着写入AOF内容的增加为避免文件膨胀,会根据规则进行命令的合并(又称AOF重写),从而起到AOF文件压缩的目的。

AOF缓冲区三种写回策略

Always:同步写回,每个写命令执行完立刻同步地将日志写回磁盘。

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

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

2、修改配置文件开启AOF

开启AOF:appendonly改为yes

策略为默认

文件保存路径

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

redis7:相对于redis6会多建一个appendonlydir文件路径

文件名称

redis6只有一个文件

redis7由Multi Part AOF的设计变成3个文件:base基本文件,incr增量文件,manifest清单文件

示例:开启AOF,写入数据

发现多一个文件夹

AOF异常文件修复

进入bin目录:cd /usr/local/bin

然后进入持久化文件,输入命令

redis-check-aof --fix appendonly.aof.1.incr.aof

"AOF is valid" 表明 AOF 文件是有效的,没有发现任何问题。

3、AOF优缺点

**AOF优点:**更好的保护数据不丢失、性能高、可做紧急恢复。

**AOF缺点:**相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdbaof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同。

由于AOF持久化是Redis不断将写命令记录到AOF文件中,随着Redis不断的进行,AOF的文件会越来越大,文件越大,占用服务器内存越大以及AOF恢复要求时间越长。

为了解决这个问题,Redis新增了重写机制,当AOF文件的大小超过所设定的峰值时,Redis就会自动启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。

4、AOF的重写机制原理

1、在重写开始前,redis会创建一个"重写子进程",这个子进程会读取现有的AOF文件,并将其包含的指令进行分析压缩并写入到一个临时文件中。

2、与此同时,主进程会将新接收到的写指令一边累积到内存缓冲区中,一边继续写入到原有的AOF文件中,这样做是保证原有的AOF文件的可用性,避免在重写过程中出现意外。

3、当"重写子进程"完成重写工作后,它会给父进程发一个信号,父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。

4、当追加结束后,redis就会用新AOF文件来代替旧AOF文件,之后再有新的写指令,就都会追加到新的AOF文件中。

5、重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。

RDB+AOF混合模式

当RDB,AOF都存在时,redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文供保存的数据集要完整。RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件。

那么只使用AOF呢?

建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份),留着rdb作为一个万一的手段。

开启混合模式:在redis.conf中redis默认开启

相关推荐
猿小喵16 分钟前
DBA之路,始于足下
数据库·dba
tyler_download25 分钟前
golang 实现比特币内核:实现基于椭圆曲线的数字签名和验证
开发语言·数据库·golang
编程、小哥哥40 分钟前
设计模式之抽象工厂模式(替换Redis双集群升级,代理类抽象场景)
redis·设计模式·抽象工厂模式
weixin_449310841 小时前
高效集成:聚水潭采购数据同步到MySQL
android·数据库·mysql
Cachel wood2 小时前
Github配置ssh key原理及操作步骤
运维·开发语言·数据库·windows·postgresql·ssh·github
standxy2 小时前
如何将钉钉新收款单数据高效集成到MySQL
数据库·mysql·钉钉
Narutolxy3 小时前
MySQL 权限困境:从权限丢失到权限重生的完整解决方案20241108
数据库·mysql
Venchill3 小时前
安装和卸载Mysql(压缩版)
数据库·mysql
Humbunklung3 小时前
一种EF(EntityFramework) MySQL修改表名去掉dbo前缀的方法
数据库·mysql·c#
PGCCC4 小时前
【PGCCC】postgresql 缓存池并发设计
数据库·缓存·postgresql