Redis数据持久化
Redis持久化RDB与AOF的区别
Redis支持两种数据持久化方式:RDB方式和AOF方式。前者会根据配置的规则定时将内存中的数据持久化到硬盘上,后者则是在每次执行写命令之后将命令记录下来。两种持久化方式可以单独使用,但是通常会将两者结合使用。
持久化
1.1、什么是持久化
内存的特点是重启系统,数据丢失;
持久化是将内存中的数据存储在磁盘上,方便Redis重启后恢复之前的数据;
1.2、持久化方式
Redis支持RDB和AOF两种持久化机制:
RDB(快照方式): RDB方式是一种快照式的持久化方法,将某一时刻的数据持久化到磁盘中。这种方式就是将内存中数据以快照的方式写入到二进制文件中 ,默认的文件名为dump.rdb。
AOF(日志追加): AOF方式是将执行过的写指令记录下来,在数据恢复时按照从前到后的顺序再将指令执行一遍。这种方式 redis 会将每一个收到的写命令都通过 write 函数追加到文件中(默认appendonly.aof)。
1.3、RDB优缺点
优点:文件体积小,恢复速度较快
RDB是一个紧凑的单一文件,方便传送,适用于灾难恢复。
与AOF相比,在恢复大的数据集的时候,RDB方式会更快一些。
缺点:不能实时存储,容易丢失数据
Redis意外宕机,可能会丢失几分钟的数据(取决于配置的save时间点)。RDB方式需要保存珍整个数据集,是一个比较繁重的工作,通常需要设置5分钟或者更久做一次完整的保存。
针对RDB不适合实时持久化的问题,Redis提供了AOF持久化方式来解决。
1.4、AOF优缺点
优点:可以实时存储或每秒钟储存一次,丢失数据少
AOF只是追加日志文件,因此对服务器性能影响较小,速度比RDB要快,消耗的内存较少。
缺点:文件体积大,恢复速度较慢(将所有指令重新执行一遍)
AOF方式生成的日志文件太大,即使通过AOF重写,文件体积仍然很大。
恢复数据的速度比RDB慢。
数据恢复操作
有AOF日志,优先使用AOF日志恢复数据;需要手动开启AOF功能;
没有AOF则使用RDB恢复数据;RDB默认开始;
如果找不到RDB,则不恢复数据;
flushall
清空 Redis 数据库,在生产环境下一定慎用,当 Redis 执行了 flushall 命令之后,则会触发自动持久化,把 RDB 文件清空。
127.0.0.1:6379> flushall
OKRDB持久化参数设置
# 配置文件
vim /usr/local/redis/etc/redis.conf
# RDB持久化自动触发条件(添加)
# 注意:当设置多个 save m n 命令时,满足任意一个条件都会触发持久化。
save 900 1
save 300 10
save 60 10000
# bgsave持久化失败,是否停止持久化数据到磁盘,yes 表示停止持久化,no 表示忽略错误继续写文件
stop-writes-on-bgsave-error yes
# rdb文件是否压缩
rdbcompression yes
# 写入文件和读取文件时是否开启rdb文件检查,检查是否有无损坏,如果在启动是检查发现损坏,则停止启动。
rdbchecksum yes
# rdb持久化后存放的文件名
dbfilename dump.rdb
# rdb持久化后文件的存放路径
dir /usr/local/redis/data
# 注意:
文件压缩要是开启的话:Redis 会采用 LZF 算法进行压缩。如果不想消耗 CPU 性能来进行文件压缩的话,可以设置为关闭此功能,这样的缺点是需要更多的磁盘空间来保存文件。配置查询/设置
config get xxx
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/redis/data"
127.0.0.1:6379> config get dbfilename
1) "dbfilename"
2) "dump.rdb"
127.0.0.1:6379> config get stop-writes-on-bgsave-error
1) "stop-writes-on-bgsave-error"
2) "yes"config set xxx
127.0.0.1:6379> config set dir "/usr/local/redis/data"
OK
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/redis/data"注意:
使用命令修改的方式,马上生效,在 Redis 重启之后就会丢失。手动修改 Redis 配置文件,想要立即生效需要重启 Redis 服务器,会一直有效。
开启AOF持久化
# 配置文件
vim /usr/local/redis/etc/redis.conf
# 修改内容
# 表示开启AOF持久化,默认是no表示关闭
appendonly yes
# AOF持久化文件名
appendfilename "appendonly.aof"
# 缓冲同步策略,默认值
appendfsync everysec
# 是否重写,默认不重写
no-appendfsync-on-rewrite no
# 注意:
设置appendfsync 控制,一共3种:
always:客户端的每一个写操作都保存到aof文件当,这种策略很安全,但是每个写都会有IO操作,所以也很慢。
everysec:每秒写入一次aof文件,因此,最多可能会丢失1s的数据。 推荐使用这种方式。
no: 交由操作系统来处理什么时候写入aof文件。更快,但也是最不安全的选择,不推荐使用。
重写方式
AOF重写过程可以手动触发和自动触发:
手动触发:直接调用bgrewriteaof命令。
自动触发:根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机
手动触发
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started自动触发
# 修改配置文件
vim /usr/local/redis/etc/redis.conf
# 配置一下内容
# AOF文件增长率(当前AOF文件大小超过上一次重写的AOF文件大小的百分之多少才会重写)
auto-aof-rewrite-percentage 100
#表示运行AOF重写时文件最小体积,默认为64MB。
auto-aof-rewrite-min-size 64mb
# 注意:
aof_current_size: aof当前尺寸(单位:字节)
aof_base_size: aof上次启动和重写的尺寸(单位:字节)AOF文件恢复
在写入AOF日志文件时,如果Redis服务器宕机,则AOF日志文件文件会出格式错误,在重启Redis服务器时,Redis服务器会拒绝载入这个AOF文件,可以通过以下步骤修复AOF并恢复数据。
备份现在AOF文件,以防万一。
使用redis-check-aof命令修复AOF文件,该命令格式如下:
# 1. 停止Redis服务(重要!)
systemctl stop redis
# 2. 备份损坏的AOF文件
cp /usr/local/redis/data/appendonly.aof /usr/local/redis/data/appendonly.aof.bak
# 3. 使用工具修复AOF文件
redis-check-aof --fix /usr/local/redis/data/appendonly.aof
# 执行后会提示 "Start fixing the AOF? (y/n):",输入 y
# 4. 查看修复结果(可选)
# 工具会输出修复摘要,显示扫描了多少条命令
# 5. 重启Redis服务
systemctl start redis
# 6. 验证数据是否恢复(可选)
redis-cli
127.0.0.1:6379> INFO persistence
# 查看 aof_last_bgrewrite_status 是否为 okRedis持久化
本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。
评论交流
欢迎留下你的想法