Redis 处理和修复不合法 AOF 文件的方法¶

当 Redis 运行在 AOF 持久化模式之下时，每条对数据库进行修改的写命令都会被追加到 AOF 文件中。

举个例子，如果当前 AOF 文件中的状态为：

SET TODAY 2013-4-26

那么当用户执行命令 SET TOMORROW 2013-4-27 之后， AOF 文件中的内容将变为：

SET TODAY 2013-4-26

SET TOMORROW 2013-4-27

Redis 服务器使用 O_APPEND 模式的 open 函数来打开 AOF 文件，并通过 write 函数来将命令内容追加到 AOF 文件的末尾。

在一般情况下， write 函数可以无错地、原子地完成 —— 除非出现以下两种情况的任意一种：

写入错误：在写入的过程中，出现写入操作被打断，磁盘空间不足，或者磁盘出现物理故障等问题。
停机故障：在写入的过程中，发生 Redis 服务器进程别强制杀死，或者服务器的宿主机器被强制停机等情况。

比如说，在以下 AOF 文件中，命令 SET TOMORROW 2013-4-27 就只有 SET 部分被写入到了 AOF 文件中：

SET TODAY 2013-4-26

SET

如果在 Redis 运行的过程中发生了写入错误，那么 Redis 将停止服务器，并打印一个错误来通知用户。

另一方面，如果在启动 Redis 时，用户试图将带有不完整数据的 AOF 文件提供给 Redis 时， Redis 将会拒绝使用用户所提供的 AOF 文件来还原数据，因为错误的 AOF 文件会破坏数据的一致性。

这篇文章将对 Redis 处理错误 AOF 文件的方法进行介绍，并讲解 AOF 修复软件 redis-check-aof 的运作原理。

前提知识¶

本文的讨论涉及 Redis 的命令、通讯协议、AOF 持久化和系统文件操作等几个方面的内容，如果读者不具备这些前提知识的话，请先阅读以下文档：

写入错误¶

前面说到， AOF 文件的写入可能遭遇两种问题，一种是写入错误，另一种是停机故障，本节先来介绍 Redis 是如何处理写入错误的。

首先要说明的是，写入错误并非致命错误，所以当出现写入错误的时候， Redis 仍然处于运行当中，因此， Redis 可以根据写入错误的情况，尝试对错误进行修复。

以下是 Redis 源码 aof.c 文件中的其中一行代码，它描述了 Redis 是如何将要追加的新内容写入到 AOF 文件里的：

nwritten = write(server.aof_fd,server.aof_buf,sdslen(server.aof_buf));

其中 server.aof_fd 是 AOF 文件的描述符， server.aof_buf 是要被写入到 AOF 文件的内容，而 sdslen(server.aof_buf) 则是被写入内容的长度。

取决于 nwritten 的值（也即是 write 函数的返回值），有以下四种情况出现：

nwritten == sdslen(server.aof_buf) ：内容全部被成功写入到 AOF 文件中。
nwritten == -1 ：写入出错，没有任何内容被写入。
nwritten == 0 ，并且 errno 被设置：和情况 2 一样。
0 <= nwritten < sdslen(server.aof_buf) ，并且当 nwritten == 0 时， errno 没有被设置：内容没有被全部写入。

在情况 1 中，写入没有发生任何错误，程序继续运行。

在情况 2 和 3 中，写入可能发生了比较严重的错误，最坏情况下，也许已经没办法再读写硬盘了：这种情况单靠 Redis 是不能处理的，而且出了这种问题， Redis 也不指望自己能再继续执行下去了，所以 Redis 会打印一个错误日志，然后直接调用 exit 退出。

情况 4 的处理方式最有趣，因为在这种情况下，磁盘有可能可以继续进行读写 —— 因此，程序会使用以下代码，尝试自动修复出错的 AOF 文件：

// 尝试移除新追加的不完整内容
if (ftruncate(server.aof_fd, server.aof_current_size) == -1) {
    redisLog(REDIS_WARNING, "Could not remove short write "
                            "from the append-only file.  Redis may refuse "
                            "to load the AOF the next time it starts.  "
                            "ftruncate: %s", strerror(errno));
}

所谓的自动修复操作，实际上就是尝试将 write 写入的不完整内容从 AOF 文件中删除掉：在上面的代码中， server.aof_current_size 记录了 AOF 文件在执行 write 之前的大小，通过 ftruncate 函数，可以将 write 写入的不完整内容删除掉，从而将 AOF 文件还原到执行 write 之前的状态。

比如说，如果这是 AOF 文件执行 write 之前的内容：

SET TODAY 2013-4-26

当 write 出错之后，文件的内容变为：

SET TODAY 2013-4-26

SET

如果 ftruncate 函数能够成功执行，那么 AOF 文件的内容将会变回执行 write 之前的样子：

SET TODAY 2013-4-26

无论自动修复是否成功，程序都会调用 exit 退出，用户必须在这之后手动重启 Redis 服务器。

自动修复能否成功取决于 ftruncate 函数能否成功执行，而 ftruncate 能否成功执行取决于磁盘能否被正常读写：

如果自动修复成功的话，那么客户在服务器退出之后，可以无须执行任何额外动作，直接重启服务器。
另一方面，如果自动修复失败，那么客户在重启服务器之前，必须使用 redis-check-aof 程序手动修复 AOF 文件，否则的话，服务器将拒绝重新启动。

停机故障¶

前面说到，在碰到无法自动修复的写入错误时，服务器会留下一个带有不完整数据的 AOF 文件，然后退出。

停机故障和无法修复的写入错误的情况一样：因为 Redis 进程被强制终结，所以 AOF 程序在执行 write 的中途会被打断，并且留下一个写入了不完整数据的 AOF 文件。

在用户启动 Redis 服务器，并且服务器试图载入 AOF 文件的数据之前，程序会先对 AOF 文件的完整性进行检查，如果 AOF 文件带有不完整的写入数据，那么为了保护数据的一致性， Redis 会拒绝载入这个 AOF 文件，并打印以下日志信息：

$ redis-server
[6842] 26 Apr 10:43:48.842 # Server started, Redis version 2.9.9
[6842] 26 Apr 10:43:48.842 # Unexpected end of file reading the append only file

Redis 附带的 redis-check-aof 可以解决这类因为 AOF 出错而无法启动的问题：它可以移除 AOF 文件所包含的不完整的数据，使得 Redis 可以重新载入 AOF 文件中的数据。

举个例子，以下是一个不完整的 AOF 文件，程序本来打算将命令 SET TOMORROW 2013-4-27 写入到 AOF 文件里，但没想到只写完 *3\r\n$3\r\nSET\r\n 就遇上了停机故障（开头的 SELECT 命令是 AOF 程序自动加上的）：

*2
$6
SELECT
$1
0
*3
$3
SET
$5
TODAY
$9
2013-4-26
*3
$3
SET

执行 redis-check-aof 程序可以检查给定的 AOF 文件是否合法（有没有包含不完整的数据）。

举个例子，我们可以用 redis-check-aof 来检查上面展示的 AOF 文件：

$ redis-check-aof invalid.aof
AOF analyzed: size=75, ok_up_to=62, diff=13
AOF is not valid

程序显示， invalid.aof 是一个不合法的 AOF 文件：它的前 62 字节是正常的，但是之后的 13 字节是错误的。

使用命令 redis-check-aof --fix 可以修复一个不合法的 AOF 文件：

$ redis-check-aof --fix invalid.aof
AOF analyzed: size=75, ok_up_to=62, diff=13
This will shrink the AOF from 75 bytes, with 13 bytes, to 62 bytes
Continue? [y/N]: y
Successfully truncated AOF

程序会定位到出错的地方，并询问用户，是否要对文件进行截断，如果选择 y 的话，就会对指定的 AOF 文件进行修复。

以下是修复后的 AOF 文件：

*2
$6
SELECT
$1
0
*3
$3
SET
$5
TODAY
$9
2013-4-26

可以看到，出错的原因 —— 那个不完整的 SET 命令已经被删除了。

现在再次使用 redis-check-aof 程序检查这个 AOF 文件的话，程序会显示这是一个合法的 AOF 文件：

$ redis-check-aof invalid.aof
AOF analyzed: size=62, ok_up_to=62, diff=0
AOF is valid

并且 Redis 也可以正确地载入这个 AOF 文件：

$ redis-server
[12948] 26 Apr 18:40:43.355 # Server started, Redis version 2.9.9
[12948] 26 Apr 18:40:43.355 * DB loaded from append only file: 0.000 seconds
[12948] 26 Apr 18:40:43.355 * The server is now ready to accept connections on port 6379

修复命令错误¶

在上一个小节，我们看到了如何使用 redis-check-aof 来检查一个 AOF 文件是否合法，并且知道了怎样使用 redis-check-aof --fix 来修复一个 AOF 文件，在这一节，我们就来看看， redis-check-aof 程序是如何定位错误的命令，以及它又是怎样删除不完整的命令内容的。

还是以前面的那个不合法的 AOF 文件作为例子：

*2
$6
SELECT
$1
0
*3
$3
SET
$5
TODAY
$9
2013-4-26
*3
$3
SET

以下是 redis-check-aof 处理上面这个 AOF 文件时的步骤：

读入 *2\r\n ，确认到接下来的是一个两个参数的命令（一个是命令、一个是参数）：
1. 读入 $6\r\n ，并确认接下来的参数为 6 字节长的 SELECT 。
2. 读入 $1\r\n ，并确认接下来的参数为 1 字节长的 0 。
读入 *3\r\n ，确认到接下来的是一个三个参数的命令（一个是命令，两个是参数）：
1. 读入 $3\r\n ，并确认 3 字节长的参数 SET 。
2. 读入 $5\r\n ，并确认 5 字节长的参数 TODAY 。
3. 读入 $9\r\n ，并确认 9 字节长的参数 2013-4-26 。
读入 *3\r\n ，确认到接下来的是一个三个参数的命令（一个是命令，两个是参数）：
1. 读入 $3\r\n ，并确认 3 字节长的参数 SET 。
2. 程序试图读入三个参数中的第二个，但是意外地发现读入已经到达了文件的末尾，出错！

上面是从协议的角度来分析 AOF 中的内容，如果我们从文本的角度来看，分析的步骤就会简单得多：

SELECT 0

SET TODAY 2013-4-26

SET

程序首先读入 SELECT 命令，还有它的参数 0 。
程序首先读入 SET 命令，接着是它的第二个参数 TODAY ，然后是它的第三个参数 2013-4-26 。
程序首先读入 SET 命令，然后试图读取第二个参数，但是失败，于是程序报告错误。

这就是 redis-check-aof 程序的运作方式 —— 按 Redis 通讯协议的格式，按顺序读入 AOF 文件中的每个命令的每个参数，并对这些参数进行检查：

如果遇到了不符合协议格式的内容，或者命令在不该结束的地方结束了，那么这个 AOF 文件就是不合法的。
如果没有发现参数错误，并且顺利地读到了文件末尾，那么这个 AOF 文件就是合法的。

每次读入一个命令之前， redis-check-aof 都会记录命令开始的偏移量，当某个命令出现错误时：

如果执行的是 redis-check-aof ，那么程序就向用户报告 AOF 文件的错误。
如果执行的是 redis-check-aof --fix ，那么程序就询问用户，要不要对 AOF 文件进行修复。

以下是 redis-check-aof 检查 invalid.aof 的结果：

$ redis-check-aof invalid.aof
AOF analyzed: size=75, ok_up_to=62, diff=13
AOF is not valid

程序显示， invalid.aof 文件总共 75 字节，文件的前 62 字节是正常的，而后面的 13 字节则是写入不完整的数据。

使用 od -c 命令，可以正好看到， 62 字节之后，就是出错的 SET 命令的协议内容：

$ od -c invalid.aof
0000000   *   2  \r  \n   $   6  \r  \n   S   E   L   E   C   T  \r  \n
0000020   $   1  \r  \n   0  \r  \n   *   3  \r  \n   $   3  \r  \n   S
0000040   E   T  \r  \n   $   5  \r  \n   T   O   D   A   Y  \r  \n   $
0000060   9  \r  \n   2   0   1   3   -   4   -   2   6  \r  \n   *   3
0000100  \r  \n   $   3  \r  \n   S   E   T  \r  \n

修复 AOF 文件的办法就是使用 ftruncate 将出错命令整个删除掉。

以下命令展示了 invalid.aof 在被修复之后的样子：

$ redis-check-aof --fix invalid.aof
AOF analyzed: size=75, ok_up_to=62, diff=13
This will shrink the AOF from 75 bytes, with 13 bytes, to 62 bytes
Continue? [y/N]: y
Successfully truncated AOF

$ od -c invalid.aof
0000000   *   2  \r  \n   $   6  \r  \n   S   E   L   E   C   T  \r  \n
0000020   $   1  \r  \n   0  \r  \n   *   3  \r  \n   $   3  \r  \n   S
0000040   E   T  \r  \n   $   5  \r  \n   T   O   D   A   Y  \r  \n   $
0000060   9  \r  \n   2   0   1   3   -   4   -   2   6  \r  \n
0000076

可以看到，不合法的 SET 命令已经被删掉了，修复后的文件只保留了合法的前 62 字节的内容。

修复事务错误¶

在上一节，我们看到了 redis-check-aof 如何分析、定位并删除出错的命令内容，从而修复一个 AOF 文件。

但是在一些情况下，单单删除一个命令并不能达到修复 AOF 文件的要求，考虑以下这个 AOF 文件：

*2
$6
SELECT
$1
0
*3
$3
SET
$5
TODAY
$9
2013-4-26
*1
$5
MULTI
*3
$3
SET

在 AOF 文件的最后，程序只写入了一个不完整的 SET 命令，但是，就算我们将这个 SET 命令删除，这个 AOF 文件也仍然不合法：因为在 SET 之前的 MULTI 命令，也同样是不合法的 —— 这个 MULTI 没有和它相对应的 EXEC 命令。

事实上，即使遇上这种情况， redis-check-aof 也有办法修复：

$ redis-check-aof invalid_transaction.aof
0x              5a: Reached EOF before reading EXEC for MULTI
AOF analyzed: size=90, ok_up_to=62, diff=28
AOF is not valid

$ od -c invalid_transaction.aof
0000000   *   2  \r  \n   $   6  \r  \n   S   E   L   E   C   T  \r  \n
0000020   $   1  \r  \n   0  \r  \n   *   3  \r  \n   $   3  \r  \n   S
0000040   E   T  \r  \n   $   5  \r  \n   T   O   D   A   Y  \r  \n   $
0000060   9  \r  \n   2   0   1   3   -   4   -   2   6  \r  \n   *   1
0000100  \r  \n   $   5  \r  \n   M   U   L   T   I  \r  \n   *   3  \r
0000120  \n   $   3  \r  \n   S   E   T  \r  \n
0000132

$ redis-check-aof --fix invalid_transaction.aof
0x              5a: Reached EOF before reading EXEC for MULTI
AOF analyzed: size=90, ok_up_to=62, diff=28
This will shrink the AOF from 90 bytes, with 28 bytes, to 62 bytes
Continue? [y/N]: y
Successfully truncated AOF

$ od -c invalid_transaction.aof
0000000   *   2  \r  \n   $   6  \r  \n   S   E   L   E   C   T  \r  \n
0000020   $   1  \r  \n   0  \r  \n   *   3  \r  \n   $   3  \r  \n   S
0000040   E   T  \r  \n   $   5  \r  \n   T   O   D   A   Y  \r  \n   $
0000060   9  \r  \n   2   0   1   3   -   4   -   2   6  \r  \n
0000076

以下是被修复后的 AOF 文件：

*2
$6
SELECT
$1
0
*3
$3
SET
$5
TODAY
$9
2013-4-26

可以看到，不止是 SET 命令， redis-check-aof 程序将整个事务，包括 MULTI 和 SET 在内的两个命令都删除了。

这就是 redis-check-aof 处理事务的方式：当它在读入 AOF 文件时，如果遇到 MULTI 命令，那么它就记录 MULTI 命令开始时的偏移量：

如果在事务的内部，有任何一个命令出错了，那么程序将删除 MULTI 命令，以及这个命令之后的所有文件内容。
如果程序能够成功找到和 MULTI 相匹配的 EXEC ，那么程序就将偏移量移动到 EXEC 的末尾，也就是下个命令开始的地方，并继续进行读入分析，一直到整个 AOF 文件读入完毕为止。

回过头来观察被修复之前的 invalid_transaction.aof 文件， redis-check-aof 将 MULTI 命令，以及命令之后的共 28 个字节都标记为非法数据，而不仅仅是标记 SET 那么简单：

$ redis-check-aof invalid_transaction.aof
0x              5a: Reached EOF before reading EXEC for MULTI
AOF analyzed: size=90, ok_up_to=62, diff=28
AOF is not valid

$ od -c invalid_transaction.aof
0000000   *   2  \r  \n   $   6  \r  \n   S   E   L   E   C   T  \r  \n
0000020   $   1  \r  \n   0  \r  \n   *   3  \r  \n   $   3  \r  \n   S
0000040   E   T  \r  \n   $   5  \r  \n   T   O   D   A   Y  \r  \n   $
0000060   9  \r  \n   2   0   1   3   -   4   -   2   6  \r  \n   *   1
0000100  \r  \n   $   5  \r  \n   M   U   L   T   I  \r  \n   *   3  \r
0000120  \n   $   3  \r  \n   S   E   T  \r  \n
0000132

小结¶

以上就是本文的所有内容了。

我们首先观察了 Redis 是如何在磁盘出错时进行自动修复的，然后学习了使用 redis-check-aof 对 AOF 文件进行手动修复的步骤，并研究了 redis-check-aof 修复一般命令、以及修复事务命令时的工作原理。

学习这些知识可以让我们更好地应对 AOF 出错之类的问题，还可以加深我们对 AOF 程序、以及 Redis 通讯协议等方面的熟悉程度，如果有兴趣进一步地了解 redis-check-aof 程序的话，可以阅读这份带注释的 redis-check-aof.c 源码。

meng

2013.4.26