1.前言
Redis支持RDB和AOF两种持久化机制,持久化功能有效避免因进程退出造成的数据丢失问题,当下次重启时利用之前持久化的文件即可实现数据恢复。
2.RDB
RDB持久化是把当前进程数据生成快照保存到硬盘的过程,触发RDB持久化的过程分为手动触发和自动触发
3.触发机制
手动触发对应的命令是save和bgsave命令:
- save命令:阻塞当前redis服务器,直到服务器RDB过程完成为止,对于内存比较大的实例会造成长时间阻塞,线上不建议使用
- bgsave命令:Redis进程执行fork操作创建子进程,RDB持久化过程有子进程负责,完成后自动结束。阻塞只发生fork阶段,一般时间很短。
bgsave命令是针对save阻塞问题做了优化,因此Redis内存所有涉及RDB的操作都采用的bgsave,而save命令已经被废弃
自动触发机制:
1)当使用save相关配置,如“save m n”。表示m秒内数据集存在n次修改时,自动触发bgsave.
2)如果从节点执行全量复制操作,主节点自动执行bgsave生成RDB文件并发送给从节点
3)执行debug reload命令重新加载redis时,也会自动触发save操作。
4)默认情况下执行shutdown命令时,如果没有开启AOF持久化功能则自动执行bgsave
5) 参数:1. dbfilename xxxxx:配置持久化RDB文件名 2. rdbcompression yes 3. rdbchecksum yes 4. stop-writes-on-bgsave-error yes
4.RDB文件处理
RDB文件位置:RDB文件一般会保存在dir配置执行的目录下,文件名通过dbfilename配置指定。可以通过执行config set dir{newdir}和config set dbfilename{newfilename}运行期动态执行,当下次运行时RDB文件会保存到新目录。
另外当遇到坏盘或磁盘写满等情况时,可以通过config set dir{newdir}在线修改文件路径到可用的磁盘路径,之后执行bgsave进行磁盘切换,同样适用于AOF持久化文件。
压缩:虽然压缩RDB会消耗CPU,但可大幅度降低文件体积,方便保存到硬盘或通过网络发送给从节点,因此线上建议开启
校验:如果redis 加载损坏的RDB文件时拒绝启动,并打印如下日志:
# short read or OOM loading DB. Unrecoverable error. aborting now
这时可以使用Redis提供的redis-check-dump工具检测RDB文件并获取对应的错误报告
5.RDB的优缺点
优点:
- RDB是一个紧凑压缩的二进制文件,代表Redis在某个时间点上的数据快照。非常适合备份,全量复制等。比如每6小时执行bgsave备份,并把RDB文件拷贝到远程机器上或者文件系统中(hdfs),用于灾难恢复
- Redis加载RDB恢复数据远远快于AOF方式
缺点:
- RDB方式数据没办法做到实时持久化/秒级持久化,因为bgsave每次运行都要执行fork操作创建子进程,属于重量级操作,频繁执行成本过高。
- RDB文件使用特定二进制格式保存,Redis版本演进过程中有多个格式的RDB版本,存在老版本Redis服务无法兼容新版本RDB格式的问题。
总结:RDB不适合实时持久化的问题,Redis提供了AOF持久化方式来解决实时持久化问题。