在指定的时间间隔内将内存中的数据集快照写入磁盘, 即 Snapshot 快照,恢复时是将快照文件直接读到内存里。
Redis 会单独创建一个子进程(fork)来进行持久化。
先将数据写入到一个临时文件中,待持久化过程完成后,再将这个临时文件内容覆盖到 dump.rdb。
整个过程中,主进程是不进行任何 IO 操作的,这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那 RDB 方式要比 AOF 方式更加的高效。
RDB 的缺点是最后一次持久化后的数据可能丢失。
dbfilename dump.rdb dump #文件名字,默认为 dump.rdb,当redis启动时会在相对目录./生成(dir配置指定)
dir ./ #相关持久化文件生成位置
stop-writes-on-bgsave-error yes #即当 redis 无法写入磁盘,关闭 redis 的写入操作。
rdbcompression yes #持久化的文件是否进行压缩存储。
rdbchecksum yes #完整性的检查,即数据是否完整性、准确性。
save #写操作在多少秒内写多久保存一次,格式:save 秒 写操作次数
以日志的形式来记录每个写操作(增量保存),将 Redis 执行过的所有写指令记录下来(读操作不记录), 只许追加文件但不可以改写文件,Redis 启动之初会读取该文件重新构建数据,换言之,如果 Redis 重启就会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
[always,everysec,no]
将操作 sync 同步到磁盘的 AOF 文件中;AOF 和 RDB 同时开启时,系统默认读取 AOF 的数据(数据不会存在丢失)
appendonly on # AOF默认开启
appendfilename "appendonly.aof" # 文件名称,保存位置收到dir配置影响
appendfsync everysec # 同步频率设置
- always
始终同步,每次 Redis 的写入都会立刻记入日志;性能较差但数据完整性比较好。
- everysec
每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失。
- no
Redis 不主动进行同步,把同步时机交给操作系统。
AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof。
相关配置如下
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64m
系统载入时或者上次重写完毕时,Redis会记录此时AOF大小,设为base_size,如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下,Redis会对AOF进行重写。
]]>官方推荐两个都启用。
如果对数据不敏感,可以选单独用 RDB。
不建议单独用 AOF,因为可能会出现 Bug。
如果只是做纯内存缓存,可以都不用。