这篇文章主要介绍”什么是RDB和AOF”,在日常操作中,相信很多人在什么是RDB和AOF问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答“什么是RDB和AOF”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
<强>复述,持久化
复述,提供了不同级别的持久化选项:
<强> RDB模式强,复述,数据库备份文件(复述,数据库备份)持久化方式,提供周期性基于时间点的数据集快照备份,,比如每小时生成一个快照备份。李李
<><强> AOF模式强,仅追加到文件(AppendOnlyFile)持久化方式,在每次数据库服务收到写操作时记录日志文件,当服务重启时,,自动回放该日志来重建原始数据集。日志中使用复述,自己的协议,并按照统一的格式,采用只追加的方法记录。当日志文件太大时,,复述,可以在后台重写该日志,生成一个最小化版本的日志文件。李李
<>你也可以完全禁用持久化,比如只要保证服务在运行中有数据或可以自动生成缓存数据即可。
<李>你还可以在同一个复述,实例上结合AOF和RDB两种持久化方式。请注意:这种方式在复述,重启时,AOF文件会被用来重建原始数据集,因为,,相对RDB周期快照的方式,AOF被认为是更完整的数据备份,比如它可以做到准实时备份(只丢失1秒的数据)。
接下来,让我们来对比RDB和AOF的优缺点:
<强> RDB优点
RDB采用一个压缩单文件来表示基于时间点的复述,数据,RDB文件是完美的备份。例如,你可以保留过去24小时的每小时的快照备份,,并且保存过去30天,每天的快照备份,当数据遇到丢失时,你可以很方便的从不同的备份粒度(版本)来恢复数据集。李李
<>RDB用来做灾备恢复非常好,因为紧凑的单文件非常便于在远端数据中心或者亚马逊S3(对象存储,可以加密)间传输。李李
<>RDB使复述性能最大化,因为复述,父进程只需要启动一个子进程完成快照备份即可,父进程不执行由备份引起的磁盘I/O
<李>与AOF模式相比,RDB在大数据集的情况下,数据恢复时,服务重启速度更快。
<强> RDB缺点
如果你想要在复述,意外停止工作时(比如断电),最小可能的丢失数据,RDB不是一个好的方案。你可以在RDB生成的地方,,配置不同的保存点(比如每5分钟,对数据集产生至少100次写操作时,创建一个保存点,你也可以配置多个保存点策略)。然而,,这样你通常会在每5分钟甚至更长时间间隔才创建RDB快照,所以当复述,异常停止工作时,你会丢失最后产生快照时间点到现在的数据。
<李>RDB会调用系统fork()方法派生一个子进程来完成数据持久化到硬盘。如果数据集比较大,Fork()方法会非常耗时,造成复述,停止为客户端服务,,停止时间可能是上微秒,如果数据集非常大并且CPU性能不是很好,停止时间可以达到1秒钟或更多。在持久化时,AOF也会调用叉()方法,,但是你可以不带任何协商(权衡),调整重写日志的频率。
<强> AOF优点
使用AOF持久化程度更高:你可以配置不同的fsync策略:
不带fsync
<李>每秒钟一次fsync
<李>每次查询的时候fsync
注:fsync (https://man7.org/linux/man-pages/man2/fsync.2.html)是系统方法,,用于将内核态的缓存数据持久化到存储设备,比如将内存数据写入硬盘
默认使用每秒执行一次fsync的策略,这种场景下,复述的写性能也能非常好,因为fsync运行在一个后台线程,而主线程会尽力完成写操作。,所以你最多丢失1秒钟的数据。
AOF日志是一个只能追加的文件,所以在断电后,该文件不会出现查找(寻求)或损坏的问题。即使由于磁盘满或其他原因导致日志中存在只写了一半的命令,,也可以使用redis-check-aof工具轻松修复。李李
<>复述,会在AOF文件太大的时候,自动在后台重写日志。重写十分安全,重写时,,复述,派生一个子进程将大的AOF文件重写为最小可用的数据集日志文件,此时有写操作时,,复述,继续追加到旧的AOF文件的同时也追加到AOF重写缓冲区aof_rewrite_buf,重写完成时,新的小AOF文件将合并缓冲区中的新数据,,最后将新的AOF文件重命名为老的AOF文件完成替换操作,以后的数据将写入新的AOF文件。
<李>AOF日志文件以一种容易理解和解析的格式依次记录了所有的操作。导出一个AOF文件非常容易。,甚至在失误执行了清除命令FLUSHALL (https://redis.io/commands/flushall),如果这时候重写操作没有被执行,,你仍然可以通过关闭服务,删除文件最后的错误命令,重启复述,完成数据恢复。
