AOF持久化以及数据恢复

最新推荐文章于 2024-07-01 08:00:00 发布

煎丶包

最新推荐文章于 2024-07-01 08:00:00 发布

阅读量977

点赞数 1

分类专栏： Redis 文章标签： redis aof 数据恢复

本文链接：https://blog.csdn.net/qq_39794062/article/details/116803970

版权

Redis 专栏收录该内容

19 篇文章 2 订阅

订阅专栏

一、Append Only FIle

AOF以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来，读操作不记录，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据。换言之redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

二、配置的位置

在redis.conf配置文件中开启appendonly，默认为no

AOF保存的是appendonly.aof文件
在这里插入图片描述

重新启动redis会生成appendonly.aof文件
在这里插入图片描述

appendonly.aof文件会记录每一次的写操作，重新启动redis会读取里面的指令再执行一次，达到恢复数据的效果。
在这里插入图片描述
appendonly.aof文件和dump.rdb文件可以共存，但是redis会先加载appendonly.aof文件

当appendonly.aof文件出现错误时，将无法启动redis，此时可以执行redis-check-aof --fix appendonly.aof来自动修复appendonly.aof文件。

三、AOF恢复

正常恢复

将redis.conf配置文件中appendonly设置为yes，启动AOF，然后把有数据的appendonly.aof文件复制一份保存到对应目录，重启redis时会重新加载appendonly.aof文件，达到恢复数据的效果。

异常恢复

如果appendonly.aof文件被损坏，可以执行redis-check-aof --fix appendonly.aof来自动修复appendonly.aof文件，重启redis时会重新加载appendonly.aof文件，达到恢复数据的效果。

四、Rewrite重写AOF文件

AOF采用文件追加方式，文件会越来越大，为了避免这种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof来重写AOF文件。

重写原理：

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

触发机制：

redis会记录上次重写时的AOF文件大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时才会触发。
在这里插入图片描述
no-appendfsync-on-rewrite：设置重写时是否还可以使用appendfsync，默认no，保证数据安全性

五、AOF优势

appendfsync always：同步持久化，每次发生数据变更会被立即记录到磁盘中，性能较差但数据完整性比较好。

appendfsync everysec：默认值，异步操作，每秒记录，如果一秒内宕机会有数据丢失。

appendfsync no：不会自动同步记录，当需要时手动执行记录。

六、AOF劣势

对于相同数据集的数据而言，appendonly.aof文件文件要远大于dump.rdb文件，恢复速度慢于dump.rdb文件。
AOF文件运行效率要慢于dump.rdb文件，每秒同步策略效率较好，不同步效率和dump.rdb文件相同。

AOF持久化方式总结：

在这里插入图片描述

AOF文件是一个只进行追加的日志文件。
redis可以在AOF文件体积变得过大时，自动的在后台对AOF文件进行重写。
AOF文件有序的保存了对数据库执行的所有写入操作，这些写入操作以redis协议的格式保存。
对于相同的数据集来说，AOF文件的体积要大于RDB文件的体积。
根据所使用的fsync策略，AOF的速度可能会慢于RDB。

RDB与AOF

RDB持久化方式能够在指定的时间间隔对数据进行快照存储。
AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾，redis还可以对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
如果只是希望数据在服务器运行的时候存在，即只做缓存处理，也可以不使用任何的持久化方式。
可以同时开启两种持久化方式，在这样情况下，当redis重启的时候会优先加载AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。RDB持久化方式的数据不实时，同时使用两种持久化方式时服务器重启也只会找到AOF文件，但是RDB也有存在的价值，因为RDB更适用于备份数据库，而AOF在不断变化不好备份，RDB还可以快速重启，而且不会有AOF文件可能潜在的BUG。两种方式并存才能更好处理意外情况。

RDB与AOF性能

因为RDB文件只用作后备数据恢复，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1 这条规则。
如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒的数据，启动脚本较简单，只加载自己的AOF文件就可以。代价是带来了持续的IO操作，而且AOF文件在重写时最后将重写过程中产生的新数据写到新文件会造成阻塞。
如果不使用AOF，仅仅靠Master-Slave Replication主从复写实现高可用性也可以，能节省掉一大笔IO,也减少了重写时带来的系统波动。主从复写的代价就是，如果Master-Slave同时挂掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。