Redis持久化操作有两个方式,RDB 和 AOF
1.1 RDB是什么
在指定的时间间隔内将内存中的数据快照写入磁盘,恢复时将快照文件直接读到内存里。
1.2 fork(子进程)
fork的作用是复制一个与当前进程一样的进程。子进程的所以数据都和原进程一样。
1.3 如何触发RDB快照
配置文件中默认的快照配置 dbfilename dump.rdb
冷拷贝后重新使用
可以 cp dump.rdb dump_new.rdb
命令 save 或者是 bgsave
Save:save 时只管保存,其它不管,全部阻塞
BGSAVE:Redis 会在后台异步进行快照操作, 快照同时还可以响应客户端请
求。可以通过 lastsave 命令获取最后一次成功执行快照的时间
执行 flushall 命令,也会产生 dump.rdb 文件,但里面是空的,无意义
1.4如何恢复
将备份文件(dump.rdb)移动到 redis 安装目录并启动服务即可
1.5 优势与劣势
优势
适合大规模的数据恢复
对数据完整性和一致性要求不高
劣势
在一定间隔时间做一次备份,所以如果 redis 意外 down 掉的话,就 会丢失最
后一次快照后的所有修改
Fork 的时候,内存中的数据被克隆了一份,大致 2 倍的膨胀性需要考虑
1.6 如何停止
动态所有停止 RDB 保存规则的方法:redis-cli config set save ""
2.1 AOF 是什么
以日志的形式来记录每个写操作,将 Redis 执行过的所有写指令记录下来(读操作
不记录), 只许追加文件但不可以改写文件。
2.2 配置
相关配置在配置文件的位置 - 在 redis.conf 搜寻### APPEND ONLY MODE ###
aof 保存的是 appendonly.aof 文件(在配置文件可修改文件名)
2.3 启动/修复/恢复
正常恢复
启动:设置 Yes
修改默认的 appendonly no,改为 yes
将有数据的 aof 文件复制一份保存到对应目录(config get dir)
恢复:重启 redis 然后重新加载
异常恢复
启动:设置 Yes
修改默认的 appendonly no,改为 yes
备份被写坏的 AOF 文件
修复:
Redis-check-aof --fix 进行修复
恢复:重启 redis 然后重新加载
2.4 优势与劣势
优势
每修改同步:appendfsync always 同步持久化 每次发生数据变更会被立即记
录到磁盘 性能较差但数据完整性比较好
每秒同步:appendfsync everysec 异步操作,每秒记录 如果一秒内宕机,有
数据丢失
不同步:appendfsync no 从不同步
劣势
相同数据集的数据而言 aof 文件要远大于 rdb 文件,恢复速度慢于 rdb
Aof 运行效率要慢于 rdb,每秒同步策略效率较好,不同步效率和 rdb 相同