Redis 实战（一）AOF 持久化配置和数据恢复

真枪实弹：AOF 持久化配置和数据恢复

大家好，我是悟空呀。

如果你曾经背过 RDB 和 AOF 的面试八股文，那么对 AOF 肯定不陌生，但如果只停留在应付面试阶段，对于提高自己的技术是远远不够的，今天，悟空就带大家来真枪实弹来看看 AOF 的持久化是怎么配置的，以及如何应用 AOF 文件进行数据恢复。

开启持久化配置

什么是 AOF 持久化

• 以独立日志的方式记录每次写命令。
• 重启时再执行 AOF 文件中的命令达到恢复数据的目的。
• 解决什么问题：解决了数据持久化的实时性。

开启持久化配置 appendonly

AOF 持久化配置默认是关闭的，所以需要手动打开。打开后就可以写入持久化文件 appendonly.aof 中，当然这个文件名字也是可以通过配置项 appendfilename 来设置的。

按照如下配置即可打开：

appendonly yes复制复制失败复制成功

对于生产环境来说，推荐打开，除非系统不关心丢失数据。

AOF 持久化流程

分为四个部分：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）

• 命令写入：所有的写入命令会追加到 aof_buff 缓冲区中。
• 文件同步：AOF 缓冲区会根据对应的策略向硬盘做同步操作。
• 文件重写：当 AOF 文件越来越大时，需要定期对 AOF 文件进行重写，达到压缩的目的。
• 重启加载：当 Redis 服务器重启时，可以加载 AOF 文件进行数据恢复。

同步写盘配置

将 aof_buf 中的数据 同步到磁盘的配置项是：appendfsync，有三种配置西昂：Always、Everysec、No。

Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；数据基本不丢失，性能较差。

Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；宕机时丢失 1s 内的数据，性能较好。

No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘；宕机时丢失数据较多。通常同步周期最长 30 秒。

持久化数据恢复

开启 AOF 持久化配置

先开启 AOF 持久化配置，并设置每秒同步 aof_buf 中的数据到磁盘。

appendonly yes复制复制失败复制成功

在我配置的环境下，这个配置文件的路径如下：

/etc/redis/6379.conf复制复制失败复制成功

开启同步配置

appendfsync 默认配置是 everysec

appendfsync everysec复制复制失败复制成功

然后重启 Redis

redis-cli shutdown
cd /etc/init.d
./redis_6379 start
ps -ef | grep redis复制复制失败复制成功

重启后，会自动生成 appendonly.aof 文件。

插入一些数据

redis-cli
set key10 100
set key11 110复制复制失败复制成功

检查 AOF 文件

进入到存放持久化文件的目录：

cd /var/redis/6379
ll
cat appendonly.aof 文件复制复制失败复制成功

生成了 appendonly.aof 文件。我们也可以看下这个文件里面存放了什么。

强制退出 Redis

强制退出 Redis 时，不会生成 RDB 文件，而且还没有到 RDB 的检查点，所以 RDB 快照不会重新生成。所以 key8 和 key 9 不存在 RDB 的快照 dump.rdb 文件中。

重启时，Redis 直接从 append.aof 文件中读取日志，恢复 Redis 内存数据。

强制和退出的步骤如下：

首先获取 Redis 的进程 id

ps -ef | grep redis复制复制失败复制成功

Redis PID=1570，然后用 kill -9 干掉 Redis 进程：

kill -9 1570复制复制失败复制成功

干掉 Redis 进程时，不会自动生成 dump.rdb 文件。

然后重启 Redis

cd /var/run
rm -rf redis_6379.pid
cd /etc/init.d
./redis_6379 start复制复制失败复制成功

检查重启后，数据是否恢复

redis-cli
get key10
get key11复制复制失败复制成功

key10 和 key11 都有数据，如下图如下：

检查 RDB 持久化文件

我们用 notepad++ 工具打开 dump.rdb 文件，可以看出确实没有 key10 和 key11。

AOF 文件重写

AOF 日志就一个，AOF 日志的大小会不断增加，如果不即时清理，将会达到很大，下次重启时，通过 AOF 日志恢复内存数据是很慢的ige过程。

Redis 重写策略：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb复制复制失败复制成功

流程：

（1）当 Redis 日志的大小超过 64 MB，且超过上次日志文件大小时，Redis 父进程 fork 一个子进程。这两个值都可以通过命令 info persistence 获取到。如下图所示：

（2）Redis 父进程 fork 一个子进程后，父进程继续响应其他命令。修改命令还是写入到 AOF 缓冲区，并根据 appendfsync 策略同步到磁盘，保证原来的 AOF 机制正常执行。

（4）新写入的命令，会通过 AOF 重写缓冲区来记录。

（5）子进程根据内存快照，按照命令合并规则写入到新的 AOF 文件。

（6）父进程把 AOF 重写缓冲区的数据追加写入到新的 AOF 文件。

AOF 文件损坏

如果 Redis 在 append 数据到 AOF 日志文件中时，机器突然宕机了，可能导致 AOF 日志文件不完整，也就是 AOF 文件损坏。

我们可以先对错误格式的 AOF 文件，先进行备份，然后使用 redis-check-aof --fix 命令来进行修复。然后使用 diff -u 对比数据的差异，查出丢失的数据。

实验步骤：

（1）拷贝一份 AOF 日志文件，这个文件是正常的文件。

cd /var/redis/6379
cp appendonly.aof /var/local/appendonly_copy.aof复制复制失败复制成功

（2）然后用 redis-check-aof 工具检查拷贝的 AOF 文件是否完整

cd /usr/local/redis-3.2.8
redis-check-aof ../../apendonly_copy.aof复制复制失败复制成功

提示 AOF 文件是有效的，占用 176 个字节，完整的字节也是 176 个，不完整的的字节为 0 个。

AOF analyzed: size=176, ok_up_to=176, diff=0
AOF is valid复制复制失败复制成功

然后编辑 appendonly_copy.aof，删掉最后的两行，使日志不完整。

再次用检查工具检查，提示 AOF 无效，总字节 167 个，完整的字节是 143 个，不完整的字节是 24 个：

AOF analyzed: size=167, ok_up_to=143, diff=24
AOF is not valid复制复制失败复制成功

我们再用检查工具修复下：

./redis-check-aof --fix ../../appendonly_copy.aof 复制复制失败复制成功

提示是否修复 AOF 文件，输入 y，最后会把文件从 167 字节截取为 143 字节，因为只有 143 字节是完整的记录：

AOF analyzed: size=167, ok_up_to=143, diff=24
This will shrink the AOF from 167 bytes, with 24 bytes, to 143 bytes
Continue? [y/N]: y
Successfully truncated AOF复制复制失败复制成功

我们打开日志文件也会发现不完整的 key11 的操作命令被删掉了：

另外也可以通过配置 aof-load-truncated 配置来兼容这种破损情况，默认是开启的。

AOF 和 RDB 同时存在

AOF 和 RDB 是可以同时工作的，只是会有限制条件：

• 同时生成了 RDB 和 AOF 文件，先使用 AOF 进行数据恢复。
• 如果 RDB 正在生成快照文件，而用户又在执行 AOF 重写命令，那么需要等到 RDB 快照生成之后，才会执行 AOF 重写。
• 如果 RDB 正在生成快照文件，那么 Redis 不会去执行 AOF 重写，相反也是。