RDB快照
RDB属于全量备份,RDB备份又分为两种BGSave与Save实现方式。
原理:主进程fork子进程,子进程将数据集写入到一个临时RDB 文件中。当子进程完成对新 RDB 文件的写入时,用新 RDB 文件替换原来的 RDB 文件,并删除旧的 RDB 文件。
优点:
非常适合保存某个时间点的数据集,比如每小时每天,可以根据需求恢复到不同版本的数据集。
RDB相对于AOF在恢复大数据集的时候回更快。
缺点:
RDB持久化数据属于重量级操作,不适合频繁执行,所以redis意外停机后持久化数据完整性没有AOF好。
经常fork子进程保存数据,当数据集比较大的时候计较耗时会影响客户端请求。
AOF追加
AOF文件会记录所有写入操作,以此来记录所有数据发生的变化,可以使用命令BgRewriteAOF发出重写AOF文件操作,Redis2.4以后版本中AOF会由redis自行触发。
原理:主进程fork子进程,对于写命令主进程会将他们写入缓存中并且写入现有的AOF文件末尾,待子进程重写完毕会发送给主进程信号,主进程会把缓存中数据追加到新AOF文件中,然后会使用新文件替换旧文件。
优点:
使用AOF策略,主线程依然可以处理客户端请求,如果出现故障最多丢失1秒数据。
AOF文件有序对数据库执行的写入操作,而且文件内容人类可读,即便不小心执行了错误的命令,在AOF文件未被重写情况下只要停止redis服务器就可以编辑AOF文件对命令进行重写或者删除命令。
缺点:
AOF文件体积通常要要大于RDB文件。
AOP启用fsync 策略后性能可能不如RDB高。
恢复数据
如果开启了两种持久化方式,redis启动后优先从AOF文件中恢复数据,因为AOF文件中数据通常相对于RDB要完整。
AOF文件损坏
当redis正在进行AOF备份是停机,如果停机造成AOF文件出错那么redis为了保证数据的一致性不被破坏,会拒接加载这个AOF文件。
1为AOF文件创建备份;
2使用redis-check-aof程序对AOF文件进行修复;
3重启redis服务器等待载入修复后的AOF文件。
持久化过程差异
RDB经测试
删除dump.rdb文件,执行bgsave会新生成一个dump.rdb文件。所以rdb将内存中数据写入到临时的RDB文件中,然后替换新的RDB文件并删除旧RDB。
AOF经测试
测试1:aof持久化策略为每次写入都持久化,然后写入set 新字符串,查看appendonly.aof文件修改时间已经改变为写入字符串的时间。
测试2:同样策略删除appendonly.aof,新写入set 新字符串,appendonly.aof文件没有重新生成,总结AOF是copy旧文件,主进程缓存新写入数据并追加现有AOF文件,待子进程发送信号,主进程将内存缓存数据追加至新appendonlt.aof文件中,然后替换新文件