在指定的时间间隔内将内存中的数据集快照写入磁盘, 也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里.rdb 保存的是dump.rdb文件
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方
,式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
fork :fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)
数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程
redis.conf配置位置:
################################ SNAPSHOTTING ################################ //快照
# save 900 1
# save 60 10000
# 分别表示900秒(15分钟)内有1个更改,300秒(5分钟)内有10个更改以及60秒内有10000个更改。
………………….
命令save或 bgsave
save:save时只管保存,其它**不管,全部阻塞
**
bgsave:Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间
以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),
只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis
重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作.Aof保存的是appendonly.aof文件
redis.conf配置位置:
############################## APPEND ONLY MODE ############################### 追加 AOF
appendonly no 默认Aof备份策略关闭
appendfilename "appendonly.aof" 默认备份文件名default: "appendonly.aof"
.
.
.
.
AOF 重写和 RDB 创建快照一样,都巧妙地利用了写时复制机制:
你可以配置 Redis 多久才将数据 fsync 到磁盘一次。有三种方式:
$ redis-check-dump –fix
$ redis-check-aof –fix
执行以下两条命令:
redis-cli config set appendonly yes
redis-cli config set save “”
**当 Redis 启动时, 如果 RDB 持久化和 AOF 持久化都被打开了, 那么程序会优先使用 AOF 文件来恢复数据集, 因为 AOF 文件所保存的数据通常是最完整的。
**
rdb优点:
1)RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份。
2)RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心, 在不考虑数据完整性,一致性的情况下,适合大批量数据的恢复,效率高
3)RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做,父进程不需要再做其他IO操作.
**rdb缺点:
1)Redis意外宕机,你可能会丢失几分钟的数据,就会丢失最后一次快照后的所有修改。
2)fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑。
AOF优点:
1)AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略:无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好,一旦出现故障,
你最多丢失1秒的数据.
AOF缺点:
1)对于相同的数据集来说,AOF 文件的体积通常要大于 RDB 文件的体积。
2)aof运行效率要慢于rdb,每秒同步策略(appendfsync everysec)效率较好,不同步效率和rdb相同。****
**
手机扫一扫
移动阅读更方便
你可能感兴趣的文章