文章目录
- 1、持久化之RDB操作
- 2、持久化之AOF操作
Redis
是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦服务器进程退出,服务器中的数据库状态也会消失。所以Redis
提供了持久化功能
1、持久化之RDB操作
RDB (Redis DataBase)
在主从复制中,rdb
就是备用了。
-
在指定的时间间隔内
将内存中的数据集快照写入磁盘
,也就是行话讲的Snapshot快照
,它恢复时
是将快照文件
直接读到内存里
。 -
Redis
会单独创建 ( fork )一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB,一般情况下不需要修改这个配置
rdb保存的文件是 dump.rdb
,都是在我们的配置文件的快照中进行配置的
触发机制
-
save
的规则满足的情况下,会自动触发rdb
规则 - 执行
flushall
命令,也会触发我们的rdb
规则 - 退出
redis
,也会产生rdb
文件 - 备份就会自动生成一个
dump.rdb
文件
如何恢复rdb文件
- 只需要将
rdb
文件放在我们redis
启动目录就可以,redis
启动的时候会自动检查dump.rdb
文件,恢复其中的数据。 - 查看需要存放的位置
rdb的优点
- 适合大规模的数据恢复
- 对数据的完整性要求不高
rdb的缺点
- 需要一定的时间间隔进行操作,如果
redis
意外宕机了,这个最后一次修改数据就没有了 - fork进程的时候,会占用一定的内容空间
注意:配置要改回去,因为我们是学习,尽量使用原来的配置
学习视频:网址
2、持久化之AOF操作
AOF (Append Only File)
将 我们的所有命令都记录下来,恢复的时候就把这个文件全部再执行一遍
以日志的形式来记录每个写操作,将Redis
执行过的所有指令记录下来(读操作不记录),只许追加文件但不可以改写文件
,redis
启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
AOF保存的是 appendonly.aof文件
append
默认是不开启的
,我们需要手动进行配置。只需要将appendonly中的no
改为yes
即可。
重启之后,redis
就可以生效了
修复
如果这个aof
文件有错位(被修改
),这时候redis
是启动不起来的,我们需要修复这个aof
文件,redis
给我们提供了一个工具 redis-check-aof
修复命令:redis-check-aof -- fix appendonly.aof
如果文件正常,重启就可以直接恢复了
重写规则说明
aof
默认就是文件的无限追加,文件会越来越大
如果aof
文件大于64m,太大了,它就会fork
一个新的进程来将我们的文件进行重写
aof的优点
aof
的配置
- 每一次修改都会同步,文件的完整性会更好
- 每秒同步一次,可能会丢失一秒的数据
- 如果是
no
的话,从不同步,效率
aof的缺点
- 相对于数据文件来说,
aof
远远大于rdb
,修复的速度也比rdb
慢 - aof运行效率也比
rdb
慢,所以我们redis
默认配置就是rdb持久化
扩展
-
RDB
持久化方式能够在指定的时间间隔内对你的数据进行快照存储 -
AOF
持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF
命令以Redis
协议追加保存每次写的操作到文件末尾,Redis
还能对AOF
文件进行后台重写,使得AOF
文件的体积不至于过大 - 只做缓存,如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化
- 同时开启两种持久化方式
- 在这种情况下,当
redis重启的时候
会优先载入AOF文件来恢复原始的数据
,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。 -
RDB
的数据不实时,同时使用两者时服务器重启也只会找AOF
文件,那要不要只使用AOF
呢? 作者建议不要,因为RDB
更适合用于备份数据库(AOF在不断变化不好备份),快速重启,而且不会有AOF可能潜在的Bug,留着作为一个万一的手段。
- 性能建议
- 因为
RDB
文件只用作后备用途,建议只在Slave上持久化RDB文件
,而且只要15分钟备份一次就够了
,只保留save 9001
这条规则 - 如果
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文件,载入较新的那个,微博就是这种架构。