标签:原因 部分 src 版本 img 操作系统 一点 选项 配置文件
在默认情况下,Redis将内存数据库快照保存到dump.rdb的二进制文件中。
可以对Redis进行设置,让它在“N秒内数据集至少有N个改动”, 这一条件被满足时,自动保存一次数据集。比如说:让Redis满足“60秒内至少有1000个键被改动”这一个条件时,自动保存一次数据集。
save 60 1000
除了在配置文件中使用save关键字设置RDB快照,还可以在命令行中手动执行命令生成RDB快照,进入redis客户端执行命令save或bgsave可以生成dump.rdb文件。
每次执行命令都会将所有redis内存快照保存到一个rdb文件里,并覆盖原有的rdb快照文件。
save是同步命令,bgsave是异步命令,bgsave会从redis主进程fork出一个子进程专门用来生成rdb二进制文件。
快照功能并不是非常durable,如果redis因为某些原因而造成故障停机,那么服务器将丢失最近写入且未保存到快照中的那些数据。从1.1版本,redis增加了一种完全durable的方式:AOF持久化,将修改的每一条指令记录进appendonly.aof中。修改配置文件来打开aof功能:
appendonly yes
打开aof功能,每当redis执行一个改变数据集的命令时,这个命令就会追加到aof文件的末尾。这样的话,当redis重新启动时,程序就会通过执行aof文件中的命令来达到重建数据集的目的。
可以配置redis多久才将命令持久化到磁盘一次。
appendfsync always:每次有新命令追加到aof文件时就执行一个持久化,非常慢但是安全
appendfsync everysec:每秒执行一次持久化,足够快(和使用rdb持久化差不多)并且在故障时只会丢失1秒钟的数据
appendfsync no:从不持久化,将数据交给操作系统来处理。redis处理命令速度加快但是不安全。
默认情况下 ,每秒执行一次fsync, 这种fsync策略可以兼顾安全性和速度。
rdb和aof的区别:
redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据,因为aof文件一般来说数据更安全一点。
二、AOF重写
aof文件里可能有太多“琐碎”指令,所以aof会定期根据内存的最新数据重新生成aof文件
有两个配置可以控制aof自动重写的频率:
auto-aof-rewrite-min-size 64mb: aof文件至少要达到64m才会触发制动重写,文件太小恢复速度本来就很快,重写的意义不大
auto-aof-rewrite-percentage 100:aof文件上一次重写后文件大小增长了100%则再次触发重写
当然aof还可以手动重写,进入redis客户端执行命令bgrewriteaof重写aof。
触发aof重写时,redis会fork一个子进程去做,不会对redis正常命令处理有太多影响。
重启redis恢复数据集时,很少会使用rdb来恢复内存状态,因为会丢失大量数据。通常会使用aof日志恢复数据,但是重放aof日志性能相对rdb来说要慢很多,这样在redis实例很大的情况下,启动需要花费很长时间。Redis4.0为了解决这个问题,带来了新的持久化选项——混合持久化。
aof-use-rdb-preamble yes
混合持久化aof文件结构:
如果开启了混合持久化,aof在重写时,不再是单纯将内存数据转换为RESP命令写入aof文件,而是将重写这一刻之前的内存做rdb快照处理,并且将rdb快照内容和增量的aof修改内存数据的命令存在一起,都写入新的aof文件,新的aof文件一开始不叫appendonly.aof,等到重写完成后,新的aof文件才会进行改名,原子的覆盖原有的aof文件,完成新旧两个aof文件的替换。
于是在redis重启的时候,可以先加载rdb文件,然后再重放增量的aof日志就可以完全替代之前的aof全量文件重放,因此重启效率大幅得到提高。
还没关注我的公众号?
标签:原因 部分 src 版本 img 操作系统 一点 选项 配置文件
原文地址:https://www.cnblogs.com/xiaoqiang-code/p/11748395.html