RDB
rdb是在指定的时间间隔内将内存中的数据集快写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。
备份是如何执行的
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感。拿RDB方式要比AOF更加高效。RDB的缺点是最后一次持久化后的数据可能丢失。
优势:
1.适合大规模的数据恢复
2.对数据完整性和一致性要求不高更适合使用
3.节省磁盘空间
4.恢复速度快
劣势:
1.fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑
2.虽然Redis再fork时使用了写时拷贝技术,但是如果数据庞大时还是会比较消耗性能。
3.在备份周期在一定间隔时间做一次备份,所以如果Redis意外down掉的话,就会丢失最后一次快照后的所有修改。
RDB的备份
模拟数据丢失
先通过config get dir 查询 dump.rdb文件的目录,一般默认在/usr/local/bin下
将dump.rdb 文件复制一份 --- cp dump.rdb d.rdb
删掉dump.rdb --- rm -f dump.rd
RDB的恢复:
1.关闭redis-server
2.将d.rdb 文件改为dump.rdb --- mv d.rdb dump.rdb
3.启动redis-server
AOF(Append Only File)
aof是以日志 的形式记录每一个操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以修改文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
AOF持久化流程
- 客户端的请求命令会被append追加到AOF缓冲区内;
- AOF缓冲区根据AOF持久化策略【always,everysec,no】将操作sync同步到磁盘的AOF文件中
- AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量
- Redis服务重启时,会重新load加载AOF文件中的写操作达到数据恢复的目的
AOF 默认不开启,可以在redis.conf配置文件中找到appendonly no改为yes
AOF 于RDB同时开启,系统默认取AOF的数据
AOF同步频率设置
appendfsync always:始终同步,每次Redis的写入都会立刻记入日志,性能较差但数据完整性比较好
appendfsync everysec :每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失。
appendfsync no:redis不主动进行同步,把同步时机交给操作系统