一、RDB 详解
RDB 是 Redis 默认的持久化方案。
就是在配置文件里面设置多久时间之内,执行了多少次写操作,
就生成一份数据快照dump.rdb文件,备份到指定是目录下。
redis.conf 文件:
以上就是900秒内写操作执行了1次 300秒/10次 60秒/10000次都会进行数据备份。
触发RDB快照:
1 在指定的时间间隔内,执行指定次数的写操作(根据配置文件中设置的来执行)
2、执行save(阻塞, 只管保存快照,其他的等待) 或者是bgsave (异步)命令
3、执行flushall 命令,清空数据库所有数据。
4、执行shutdown 命令,保证服务器正常关闭且不丢失任何数据
通过RDB文件恢复数据
将dump.rdb 文件拷贝到redis的安装目录的bin目录下,重启redis服务即可。
在实际开发中,一般会考虑到物理机硬盘损坏情况,选择备份dump.rdb 。
RDB 的优缺点
优点是只包含一个文件,这样非常方便进行备份。
缺点就是无法实现实时性,因为rdb是有时间间隔的,这个间隔期间出现问题了,数据就没有备份到。
如果数据量过大,fork一个子进程进行备份的时候,会很耗时。
二、AOF 详解
Redis 默认不开启。它的出现是为了弥补RDB的不足(数据的不一致性),
所以它采用日志的形式来记录每个写操作,并追加到文件中。
Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
从配置文件了解AOF
打开 redis.conf 文件,找到 APPEND ONLY MODE 对应内容
1、 redis 默认关闭,开启需要手动把no改为yes
appendonly yes
2、指定本地数据库文件名,默认值为 appendonly.aof
appendfilename "appendonly.aof"
3、指定更新日志条件
#appendfsync always
#appendfsync everysec
#appendfsync no
always:同步持久化,每次发生数据变化会立刻写入到磁盘中。
性能较差当数据完整性比较好(慢,安全)。
everysec:出厂默认推荐,每秒异步记录一次(默认值)
no:不同步
4 、配置重写触发机制
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发备份。
一般都设置为3G,64M太小了。
根据AOF文件恢复数据
正常情况下,将appendonly.aof 文件拷贝到redis的安装目录的bin目录下,
重启redis服务即可。
AOF的重写机制
AOF的工作原理是将写操作追加到文件中,文件的冗余内容会越来越多。
当AOF文件的大小超过所设定的阈值时,Redis就会对AOF文件的内容压缩。
重写的原理:
Redis 会fork出一条新进程,读取内存中的数据,并重新写到一个临时文件中。
并没有读取旧文件(你都那么大了,我还去读你???)。最后替换旧的aof文件。
这个新文件里面会优化语句,比如多条合并成一条指令,达到瘦身的目的。
AOF 的优缺点
优点:数据的完整性和一致性更高
缺点:因为AOF记录的内容多,文件会越来越大,数据恢复也会越来越慢。
三、总结:
Redis 默认开启RDB持久化方式,在指定的时间间隔内,执行指定次数的写操作,则将内存中的数据写入到磁盘中。
RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
Redis 需要手动开启AOF持久化方式,默认是每秒将写操作日志追加到AOF文件中。
AOF 的数据完整性比RDB高,但记录内容多了,会影响数据恢复的效率。
Redis 针对 AOF文件大的问题,提供重写的瘦身机制。
若只打算用Redis 做缓存,可以关闭持久化。
若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份,留一后手。AOF出问题了,还有RDB。
版权声明:本文为qq_39188150原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明。