Redis持久化之RDB、AOF

2022-08-22 | 0 评论 | 0 浏览

Redis持久化之RDB、AOF

1.总体介绍

官网介绍：http://www.redis.io

Redis 提供了2个不同形式的持久化方式。

RDB（Redis DataBase）

AOF（Append Of File）

2.Redis持久化之RDB

1.是什么

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

2.备份如何执行

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

3.Fork

1.Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

2.在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”

3.一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

4.RDB持久化流程

5.dump.rdb文件

在redis.conf中配置文件名称，默认为dump.rdb

# The filename where to dump the DB
dbfilename dump.rdb

6.配置位置

rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
#默认为Redis启动时命令行所在的目录下
dir ./

7.如何触发RDB快照，保存策略

1.配置文件中默认的快照配置

# Save the DB to disk.
#
# save <seconds> <changes>
#
# Redis will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# Snapshotting can be completely disabled with a single empty string argument
# as in following example:
#使用一个空字符串参数可以完全禁用快照
# save ""
#
# Unless specified otherwise, by default Redis will save the DB:
#   * After 3600 seconds (an hour) if at least 1 key changed
#   * After 300 seconds (5 minutes) if at least 100 keys changed
#   * After 60 seconds if at least 10000 keys changed
#
# You can set these explicitly by uncommenting the three following lines.
#在3600秒内至少有一个key发送了改变
# save 3600 1
#在300秒内至少有100key发生了改变
# save 300 100
#在60秒内至少有10000个key发生了改变
# save 60 10000

2.命令save VS bgsave

save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议。**bgsave：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。**可以通过lastsave 命令获取最后一次成功执行快照的时间

3.flushall命令

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

4.Save

格式：save 秒钟写操作次数

RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，

默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。

**禁用:**不设置save指令，或者给save传入空字符串

5.stop-writes-on-bgsave-error

当Redis无法写入磁盘(比如：磁盘被占满)的话，直接关掉Redis的写操作。推荐yes.

# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes

6.rdbcompression 压缩文件

对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。

如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。推荐yes.

# Compress string objects using LZF when dump .rdb databases?
# By default compression is enabled as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes

7.rdbchecksum 检查完整性

# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
#开启快照完整性检查
rdbchecksum yes

在存储快照后，还可以让redis使用CRC64算法来进行数据校验，

但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能,推荐yes开启.

8.rdb的备份

将备份的.rdb文件修改为dump.rdb即可，注意dump.rdb默认在Redis启动时命令行所在的目录下

[root@bogon bin]# cp dump.rdb dump.rdb.bak
[root@bogon bin]# ls -l
总用量 18852
-rw-r--r--. 1 root root     156 8月  22 07:51 dump.rdb
-rw-r--r--. 1 root root     156 8月  22 08:42 dump.rdb.bak
-rwxr-xr-x. 1 root root 4833392 8月  20 14:40 redis-benchmark
lrwxrwxrwx. 1 root root      12 8月  20 14:40 redis-check-aof -> redis-server
lrwxrwxrwx. 1 root root      12 8月  20 14:40 redis-check-rdb -> redis-server
-rwxr-xr-x. 1 root root 5003408 8月  20 14:40 redis-cli
lrwxrwxrwx. 1 root root      12 8月  20 14:40 redis-sentinel -> redis-server
-rwxr-xr-x. 1 root root 9450240 8月  20 14:40 redis-server
#删除dump.rdb文件
[root@bogon bin]# rm dump.rdb
rm：是否删除普通文件 "dump.rdb"？y
[root@bogon bin]# ls -l
总用量 18848
-rw-r--r--. 1 root root     156 8月  22 08:42 dump.rdb.bak
-rwxr-xr-x. 1 root root 4833392 8月  20 14:40 redis-benchmark
lrwxrwxrwx. 1 root root      12 8月  20 14:40 redis-check-aof -> redis-server
lrwxrwxrwx. 1 root root      12 8月  20 14:40 redis-check-rdb -> redis-server
-rwxr-xr-x. 1 root root 5003408 8月  20 14:40 redis-cli
lrwxrwxrwx. 1 root root      12 8月  20 14:40 redis-sentinel -> redis-server
-rwxr-xr-x. 1 root root 9450240 8月  20 14:40 redis-server
#将dump.rdb.bak 修改为dump.rdb
[root@bogon bin]# mv dump.rdb.bak  dump.rdb
[root@bogon bin]# ls -l
总用量 18848
-rw-r--r--. 1 root root     156 8月  22 08:42 dump.rdb
-rwxr-xr-x. 1 root root 4833392 8月  20 14:40 redis-benchmark
lrwxrwxrwx. 1 root root      12 8月  20 14:40 redis-check-aof -> redis-server
lrwxrwxrwx. 1 root root      12 8月  20 14:40 redis-check-rdb -> redis-server
-rwxr-xr-x. 1 root root 5003408 8月  20 14:40 redis-cli
lrwxrwxrwx. 1 root root      12 8月  20 14:40 redis-sentinel -> redis-server
-rwxr-xr-x. 1 root root 9450240 8月  20 14:40 redis-server
[root@bogon bin]# redis-cli 
127.0.0.1:6379> SHUTDOWN
not connected> exit
[root@bogon bin]# ps -ef|grep redis
root     42830 42446  0 08:44 pts/2    00:00:00 grep --color=auto redis
[root@bogon bin]# redis-server /etc/redis.conf 
[root@bogon bin]# redis-cli 
127.0.0.1:6379> keys *
1) "name"
2) "k5"
3) "age"
4) "k4"
5) "hh"
6) "nickname"
7) "k2"
127.0.0.1:6379>

9.优势

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

2.对数据完整性和一致性要求不高更适合使用

3.节省磁盘空间

4.恢复速度快

10.劣势

1.Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

2.虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

3.在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

11.如何停止

动态停止RDB：redis-cli config set save ""#save后给空值，表示禁用保存策略

12.总结

3.Redis持久化之AOF

1.是什么

AOF（Append Only File）

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

2.AOF持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

3.AOF默认不开启

可以在redis.conf中配置文件名称，默认为 appendonly.aof

AOF文件的保存路径，同RDB的路径一致。

################################# TLS/SSL #####################################

# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.
# 默认为no表示关闭aof,yes开启aof
appendonly yes
# The name of the append only file (default: "appendonly.aof")
#默认的文件名，文件所在位置默认为Redis启动时命令行所在的目录下
appendfilename "appendonly.aof"

4.AOF和RDB同时开启，redis听谁的？

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

可以看到我们刚刚开启了aof，redis从aof读取数据，此时数据时空的

5.AOF启动/修改/恢复

AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

正常恢复

1.修改默认的appendonly no，改为yes

2.将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)

3.恢复：重启redis然后重新加载

#连接redis客户端
[root@bogon bin]# redis-cli
#我们刚刚开启了aof，此时文件数据为空
127.0.0.1:6379> keys *
(empty array)
#向reids中重新设置几个值
127.0.0.1:6379> set name gukong
OK
127.0.0.1:6379> set nickname kakaluote
OK
127.0.0.1:6379>

再次查看aof文件，发现aof文件的大小从0变成了100，说明数据已经写入到了aof文件中

#拷贝aof文件
[root@bogon bin]# cp appendonly.aof appendonly.aof.bak
#删除aof文件
[root@bogon bin]# rm appendonly.aof
rm：是否删除普通文件 "appendonly.aof"？y
#关闭redis
127.0.0.1:6379> SHUTDOWN
not connected> exit
#将appendonly.aof.bak改为 appendonly.aof
[root@bogon bin]# mv appendonly.aof.bak appendonly.aof
#重启redis
[root@bogon bin]# redis-server /etc/reids.conf
#连接redis客户端
[root@bogon bin]# redis-cli 
#查看所有的key，发现数据成功恢复了
127.0.0.1:6379> keys *
1) "nickname"
2) "name"
127.0.0.1:6379>

异常恢复

1.修改默认的appendonly no，改为yes

2.如遇到AOF文件损坏，进入到Redis启动时命令行所在的目录下，cd /usr/local/bin 通过 redis-check-aof --fix appendonly.aof（*.aof文件）进行恢复

3.备份被写坏的AOF文件

4.恢复：重启redis，然后重新加载

vi appendonly.aof

[root@bogon bin]# redis-check-aof --fix appendonly.aof 
0x              64: Expected prefix '*', got: 'h'
AOF analyzed: size=107, ok_up_to=100, diff=7
#将aof还原到破损之前的大小
This will shrink the AOF from 107 bytes, with 7 bytes, to 100 bytes
Continue? [y/N]: y
Successfully truncated AOF

6.AOF同步频率设置

appendfsync always

始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no

redis不主动进行同步，把同步时机交给操作系统。

7.Rewrite压缩

1.是什么：

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

2.重写原理，如何实现重写

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

no-appendfsync-on-rewrite：

如果 no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）

如果 no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

触发机制，何时重写

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）

auto-aof-rewrite-min-size：比如说上一次AOF rewrite之后，是128mb

然后就会接着128mb继续写AOF的日志，如果发现增长的比例，超过了之前的100%，256mb，就可能会去触发一次rewrite，但是此时还要去跟min-size，64mb去比较，256mb > 64mb，才会去触发rewrite 一般这两个参数保持默认基本不用去动

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,

如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

3、重写流程

（1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。

（2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。

（3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。

（4）1).子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。

（5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

8.优势

备份机制更稳健，丢失数据概率更低。

2.可读的日志文本，通过操作AOF稳健，可以处理误操作。

9.劣势

1.比起RDB占用更多的磁盘空间。

2.恢复备份速度要慢。

3.每次读写都同步的话，有一定的性能压力。

4.存在个别Bug，造成恢复不了。

10.总结

4.总结(Which one)

官方推荐两个都启用。

如果对数据不敏感，可以选单独用RDB。

不建议单独用 AOF，因为可能会出现Bug。

如果只是做纯内存缓存，可以都不用。

标题：Redis持久化之RDB、AOF
作者：llp
地址：https://blog.llp1110.cn/articles/2022/08/22/1661135371224.html