Redis持久化: .rdb 和 .aof
Redis为什么要持久化? Redis是保存在内存中,断电数据消失。为了能够在重启后也保留数据,则需要对数据持久化。
Redis自带了两种持久化方式:RDB和AOF。
在指定的时间间隔内(可以在service.conf 中找关键字:save “”),将内存的数据集快照(snapshot)写入磁盘,数据恢复时,是直接读取rdb文件到内存。
整个过程,主进程不进行IO操作,确保了高性能。
我们知道save “” 是有多少秒内多少次操作才进行数据集快照保存,所以会存在恰巧不满足条件的那一部分时间的数据没有持久化,从而丢失的可能。如果数据量很大,而且对数据的完整性恢复不那么敏感,那么RDB方式要比AOF方式要高效。
没有修改默认配置的话,.rdb文件是在我们的安装目录(可以查看redis.conf文件
# The filename where to dump the DB
# rdb的文件名
dbfilename dump.rdb
# 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.
# rdb文件保存的路径
dir ./
)
触发持久化的条件:
- save条件满足,自动触发RDB规则
- 执行flushall命令,也会立即触发RDB规则
- 退出redis,也触发RDB规则
RDB文件存在,但是提示不能登陆,有可能是文件损毁,如何修复?
在我们的安装目录,可以看到里面有个 redis-check-rdb,启动它,这是redis自带的修复工具。
从其他地方移过来的RDB文件应该放在哪,才能恢复文件里的数据到内存?
在Redis客户端执行
config get dir
得到一个路径,放在这个路径里面就行。
RDB的优缺点:
-
优点:1 适合大规模数据的恢复 2 对数据的完整性要求不高
-
缺点:1 需要一定的时间间隔进程进行操作,如果意外断电,最后一次修改的数据则丢失。 2 fork子进程的时候,会占用一定内存空间。
-
AOF(Append Only File)
AOF是什么,是一个文件,可以文本编辑器查看,把我们所有的命令记录下来,数据恢复的时候,再把这个文件全部执行一遍。
通过service.conf中
# Please check http://redis.io/topics/persistence for more information.
# 默认是不开启aof模式的,默认是RDB持久化,大部分情况下,rdb够用
appendonly no
# The name of the append only file (default: "appendonly.aof")
# aof持久化的文件名
appendfilename "appendonly.aof"
设置为yes开启,然后重启生效
持久化规则:
#每次持久化都会sync,消耗性能
# appendfsync always
#每秒执行sync,可能会丢失这一秒的数据
appendfsync everysec
# 永不sync,这个时候操作系统自己去执行同步,速度最快!
# appendfsync no
文件存储大小
#改为yes后,文件会无限变大
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
#大于64M,则追加一个文件
auto-aof-rewrite-min-size 64mb
修复AOF文件
执行redis-check-aof
优缺点:
- 优点:设置为每一次修改都同步,文件完整性最好;每秒都同步,可能会丢失一秒数据;从不同步,效率最高。
- 缺点:AOF文件大于RDB文件,修复速度慢于RDB;运行速度比RDB慢
总结:
-
RDB持久化能够在指定时间间隔对数据进行数据集快照存储。
-
AOF持久化每次记录写操作,当服务器重启的时候,会重新执行这些命令。
-
如果单纯作为缓存,希望只是服务器运行的时候这些存在,运行重启后redis没有数据,那么可以不用任何持久化。
-
同时开启RDB和AOF:这种情况会优先载入AOF文件来恢复数据,因为一般情况AOF比RDB存储的更详细;但是仍推荐用RDB恢复,因为RDB对于大数据量的恢复有优势(速度快,存储量多)
-
性能建议(摘自狂神说的文章,我还需要消化一下)
因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够
了,只保留 save 900 1 这条规则。
如果Enable AOF ,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自
己的AOF文件就可以了,代价一是带来了持续的IO,二是AOF rewrite 的最后将 rewrite 过程中产
生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量减少AOF rewrite
的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上,默认超过原大小100%大小重
写可以改到适当的数值。
如果不Enable AOF ,仅靠 Master-Slave Repllcation 实现高可用性也可以,能省掉一大笔IO,也
减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉,会丢失十几分钟的数据,
启动脚本也要比较两个 Master/Slave 中的 RDB文件,载入较新的那个,微博就是这种架构。