突击Redis数据库(五) Redis的持久化之RDB与AOF
2020-07-24 14:34
309 查看
一. 持久化
Redis 主要是工作在内存中。 内存本身就不是一个持久化设备,断电后数据会清空。所以 Redis 在工作过程中,如果发生了意外停电事故,如何尽可能减少数据丢失。
二. RDB (Redis DataBase)
1. RDB 简介:
RDB:在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的 Snapshot 快照,它恢复时是将快照文件直接读到内存里。 快照名:dump.rdb 工作机制:每隔一段时间,就把内存中的数据保存到硬盘上的指定文件中。 RDB 是默认开启的! Redis 会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件 替换上次持久化好的文件。整个过程中,主进程是不进行任何 IO 操作的,这就确保了极高的性能如果需要进行大规模数据的恢复, 且对于数据恢复的完整性不是非常敏感,那 RDB 方式要比 AOF 方式更加的高效。
RDB 的缺点是最后一次持久化后的数据可能丢失。
2. RDB 保存策略:
3. RDB 常用属性配置:
4. RDB 数据丢失的情况:
两次保存的时间间隔内,服务器宕机,或者发生断电问题。
5. RDB 的触发:
6. RDB 的优缺点:
三. AOF (Appen Only File)
1. AOF 简介:
AOF 是以日志的形式来记录每个写操作,将每一次对数据进行修改,都把新建、修改数据的命令保存到指定文件中(appendonly.aof)。 Redis 重新启动时读取这个文件(appendonly.aof),重新执行新建、修改数据的命令恢复数据。 默认不开启,需要手动开启。 AOF 文件的保存路径,同 RDB 的路径一致。 AOF在保存命令的时候,只会保存对数据有修改的命令,也就是写操作! 当 RDB和 AOF存的不一致的情况下,按照 AOF来恢复。因为 AOF是对 RDB的补充。备份周期更短,也就更可靠。
2. AOF 保存策略:
appendfsync always:每次产生一条新的修改数据的命令都执行保存操作;效率低,但是安全! appendfsync everysec:每秒执行一次保存操作。如果在未保存当前秒内操作时发生了断电,仍然会导致一部分数据丢失(即 1 秒钟的数据)。 appendfsync no:从不保存,将数据交给操作系统来处理。更快,也更不安全的选择。 推荐(并且也是默认)的措施为每秒 fsync 一次, 这种 fsync 策略可以兼顾速度和安全性。
3. AOF 常用属性:
4. AOF 文件的修复:
如果 AOF 文件中出现了残余命令,会导致服务器无法重启。此时需要借助 redis-check-aof 工具来修复! 命令: redis-check-aof --fix 文件
5. AOF 的优缺点:
优点:
备份机制更稳健,丢失数据概率更低 可读的日志文本,通过操作 AOF 稳健,可以处理误操作
缺点:
比起 RDB 占用更多的磁盘空间 恢复备份速度要慢 每次读写都同步的话,有一定的性能压力 存在个别 Bug,造成恢复不能
四. 备份建议
1. 如何看待数据“绝对”安全
2. 官方建议:
总结:如果对数据不敏感,可以选单独用 RDB;不建议单独用 AOF,因为可能出现 Bug;如果只是做纯内存缓存,可以都不用。
相关文章推荐
- 非关系型数据库--redis的持久化策略(RDB,AOF)介绍及配置
- 使用AOF持久化文件实现还原Redis数据库并得到RDB持久化文件
- Redis持久化(RDB+AOF)与容灾备份
- Redis持久化之 RDB & AOF
- Redis持久化存储(AOF与RDB两种模式)
- redis 持久化 AOF RDB
- 《面试官之你说我听》:简明的图解Redis RDB持久化、AOF持久化
- Redis持久化方式AOF和RDB
- Redis系列(三):Redis的持久化机制(RDB、AOF)
- 第十章 Redis持久化--RDB+AOF
- redis数据库持久化AOF的设置
- Redis持久化之RDB与AOF
- redis持久化RDB和AOF
- redis持久化RDB和AOF
- Redis数据持久化-----RDB和AOF详解
- redis持久化rdb和aof
- redis的 rdb 和 aof 持久化的区别
- Redis之持久化操作——RDB和AOF
- redis持久化RDB和AOF
- redis的 rdb 和 aof 持久化的区别