redis数据持久化方法:
- RDB 是将某一时刻redis中所有的数据的快照写入硬盘。
- AOF(append-only file) 记录每次对redis服务器的写操作,当服务器重启时会重新执行这些命令来恢复原始数据,AOF以redis协议追加保存每次写的操作到文件末尾
两种数据持久化的优缺点
RDB的优点
- 文件非常紧凑,它保存了某个时间点redis里面的数据,适合用来备份redis里面数据,比如你每一小时保存一下过去24小时的数据,每天保存一下过去10天的数据,这样即使redis出了问题也可以通过备份的快照文件来恢复到不同时间点的数据
- RDB就一个紧凑的单一文件,可以方便的迁移到其他服务器或者数据中心,非常适合用于灾难的恢复
- RDB在进行备份时父进程唯一需要做的就是fork一个子进程,接下来的工作全部交给子进来完成,父进程不需要进行任何IO操作,所以RDB持久化可以最大化redis的性能
- 与AOF相比,恢复大量的数据时,RDB会比AOF要快一些
RDB的缺点
- 如果redis宕机,会丢失从上次备份点到出问题时间点的数据,如果希望redis意外停止工作的情况下丢失的数据最少,那么RDB持久化不适合你
- RDB需要经常fork子进程来保存数据集到硬盘上,当数据集比较大时,fork的过程非常耗时,可能会导致redis在一些毫秒级内不能响应客户端的请求,如果CPU不是很好的情况下,这种情况可能会持续1秒。AOF也需要fork子进程,但是你可以调节重写日志文件的频率来提高数据集的耐久度
AOF优点
- AOF比RDB相对要更持久一些,也就是说redis出现意外问题导致不可用时,丢失的数据相对来说要少一些。有三种不同的fsync策略:
- appendfsync no 操作系统来决定何时进行同步
- appendfsync always 每个redis写操作,都会同步到硬盘,会降低redis的速度
- appendfsync everysec 每秒执行一次同步,对redis的性能影响很小,就算出现故障也只会丢失一秒钟的数据
- AOF文件是一个只追加的日志文件,所以不需要写入seek,即使由于某些原因未执行完整的写入命令,你也可以使用redis-check-aof工具来修复这些问题
- redis可以在AOF文件变得过大时,自动的在后台对AOF进行重写。重写的过程绝对安全,因为redis在创建AOF文件过程中,会继续将命令追加到现有的AOF文件里面,即使重写过程发生宕机,现有的AOF文件也不会丢失。而一旦新AOF文件创建完毕,redis会从旧的AOF文件切换到新的AOF文件,并开始对新AOF文件进行追加操作
- AOF文件中有序的保存了对redis的所有写命令,这些命令以redis协议来保存,因此文件很容易读懂,假如你不小心进行了flushall命令,但只要AOF文件未被重写,那么只要停服务器,移除AOF文件中记录的flushall命令,并重启redis,数据就会恢复到执行flushall命令之前的状态
AOF缺点
- 对于相同的数据集来说,AOF文件大小要比RDB文件大
- 根据所使用的同步策略,AOF的速度可能会慢于RDB。关闭AOF同步可以让AOF与RDB的速度一样快。
该如何选择使用哪种持久化方式
- 两种持久化方式可以同时使用,也可以单独使用
- 一般为了数据的安全性考虑,推荐同时使用两种持久化方式
- 如果你非常在意执行的效率,可以承受数分钟之内的数据丢失,可以只使用RDB方式
- 有很多人都只使用AOF方式,不推荐这么做,因为定时生成RDB快照文件便于数据的备份,如果想恢复到某个时间点的备份数据,用RDB方式就很方便了,而且RDB方式恢复数据要比AOF快
持久化相关参数配置
save 60 1000
stop-writes-on-bgsave-error yes
rdbcompression yes
Rdbchecksum yes
dbfilename dump.rdb
dir ./
appendonly yes
appendfsync always
appendfsync everysec
appendfsync no
no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb