实验环境注意:
文章后来经过修正后的实验环境是:centos8.2+redis6.0.6
说明:
redis支持RDB和AOF两种持久化机制,持久化可以避免因进程退出而造成数据丢失。
redis配置文件默认开启rdb,禁用aof。
一、RDB持久化
RDB持久化的本质是将redis中内存的数据做一个快照保存到硬盘进行备份。它有以下特点:
- redis配置文件默认开启的持久化机制
- 当达到一定条件时redis会自动进行rdb持久化,触发rdb自动持久化的配置参考下面,他们是“或”的关系,即:只要有一个条件满足就会自动执行持久化
save 900 1 #900秒内有至少1个键被更改则进行快照;
save 300 10 #300秒内有至少10个键被更改则进行快照;
save 60 10000 #60秒内有至少10000个键被更改则进行快照。
- 每次rdb的持久化都是一个全新的快照,不会修改已有的备份文件。
- rdb持久话的时候会先在磁盘的临时目录生成快照,生成完成后才会拷贝到配置的指定位置(同名文件会替换)。
- rdb持久化时可以对数据进行压缩
- 也可以手动进行持久化(
save
/bgsave
)
save命令: 阻塞当前Redis,直到RDB持久化过程完成为止,若内存实例比较大会造成长时间阻塞,线上环境不建议用它。
bgsave命令: redis进程执行fork操作创建子线程,由子线程完成持久化,阻塞时间很短(微秒级),是save的优化。
- 执行redis-cli shutdown关闭redis服务时,如果没有开启AOF持久化,自动执行bgsave。(如果开启了aof,我们仍然可以执行shutdown save强制持久化到rdb文件)
- 缺点:无法做到实时持久化,每次都要创建子进程,频繁操作成本过高
bgsave运行流程:
1.1 实验观察redis默认的rdb配置
首先,使用命令/usr/local/redis/bin/redis-server
以默认配置开启redis:
然后,使用另外一个客户端进行连接,查看默认配置如下:
可以看到,rdb默认被开启,并且触发条件设置为3600 1 300 100 60 10000
,持久化时开启压缩。
1.2 实验save、bgsave命令以及shutdown命令
在上面开启的redis基础上,我们先执行shutdown命令,观察是否自动持久化rdb数据,首先看一下备份目录:
可以看到,此时并没有dump.rdb文件
我们执行shutdown
命令:
可以看到,在客户端执行shutdown
后,服务端的日志上已经输出了rdb持久化的信息了。
此时,我们看一下备份目录:
由此可以看到:shutdown
命令执行后,redis是自动进行rdb持久化的。
1.3 rdb持久化文件的恢复
恢复很简单,先把redis服务关掉,然后将rdb文件拷贝到redis配置文件指定的位置,最后启动redis即可。
二、AOF持久化
由于rdb持久化并不会实时的进行备份(需要达到一定条件或手动触发),所以仅使用rdb进行持久化数据是存在数据丢失的风险的。幸好,redis提供了AOF持久化方式来解决这一问题。
redis默认没有开启aof持久化,需要我们手动开启。
配置参数,参照:
appendonly yes #开启AOF持久化功能;
dir ./ #aof文件存储的目录,这个配置与rdb共用
appendfilename appendonly.aof #AOF持久化保存文件名;
appendfsync always #每次执行写入都会执行同步,最安全也最慢;
#appendfsync everysec #每秒执行一次同步操作;
#appendfsync no #不主动进行同步操作,而是完全交由操作系统来做,每30秒一次,最快也最不安全;
auto-aof-rewrite-percentage 100 #当AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写,如果之前没有重写过,则以启动时的AOF文件大小为依据;
auto-aof-rewrite-min-size 64mb #允许重写的最小AOF文件大小配置写入AOF文件后,要求系统刷新硬盘缓存的机制。
AOF持久化的工作示意图如下:
AOF持久化流程: 命令写入(append),文件同步(sync),文件重写(rewrite),重启加载(load)
流程说明:
- 1,所有的写入命令(set hset)会append追加到aof_buf缓冲区中
- 2,AOF缓冲区向硬盘做sync同步
- 3,随着AOF文件越来越大,需定期对AOF文件rewrite重写,达到压缩
- 4,当redis服务重启,可load加载AOF文件进行恢复
从aof文件中恢复?
redis支持同时开启rdb和aof两个持久化机制,它们在备份的过程中互不影响,但是在恢复时是以AOF方式为主的,因为AOF方式相比RDB方式保存了更全的数据。
恢复的时候和rdb一样,把aof文件拷贝到配置文件指定的目录即可,然后启动redis,它就会读取aof中的命令,等将这些命令执行完了,也就恢复完成了。因为是通过执行命令恢复的,所以时间可能要长点。。。
2.1 实验 aof持久化
准备配置文件如下:
redis.conf
#修改端口为6500
port 6500
#运行模式改为后台运行
daemonize yes
#后台运行模式时用来记录进程ID的文件
pidfile /var/run/redis_6500.pid
#redis日志文件
logfile "/usr/local/redis/bin/log.txt"
#数据文件
dbfilename dump-6500.rdb
#连接密码
requirepass 123456
#持久化数据保存目录
dir "/usr/local/redis/bin/"
#开启aof持久化
appendonly yes
#aof持久化文件名称
appendfilename appendonly.aof
#每次执行写入都会执行同步,最安全也最慢
appendfsync always
启动redis:
客户端连接:
此时观察备份目录:
现在只能看到一个空的aof文件(可以打开看看,确实是空的)。
在客户端执行几个命令,如下:
此时我们看一下aof文件:
可以看到,我们执行的命令都在这里面有记录。(另外,因为我们开启了aof,所以如果我们执行shutdown命令,那么不会默认执行bgsave的,你可以试一下。)如果我们指定了过期时间怎么样呢,恢复时已经过期的数据还会重现嘛?
答:肯定不能重现。
如下图所示:
三、其他的持久化方式
redis本身仅提供了rdb和aof两种方式的持久化,它们都各有优缺点。不过当我们选择主从方式运行redis的时候,我们又多了一种持久化方式:
我们将数据持久化任务加在从redis上,主redis上不再使用rdb或aof,这样能减轻主redis的压力。如果我们担心从redis服务器挂掉的话,可以再增加一个从redis去持久化数据。。。