故障恢复

概述：

用户必须做好相应的准备来应对Redis 的系统故障。如果我们决定要将Redis 用作应用程序唯一的数据存储手段， 那么就必须确保Redis 不会丢失任何数据。跟提供了ACID（ACID 是指原子性、一致性、隔离性和持久性，如果一个数据库想要实现可靠的数据事务，那么它就必须保证ACID 性质。）保证的传统关系数据库不同，在使用Redis为后端构建应用程序的时候，用户需要多做一些工作才能保证数据的一致性。

验证快照文件和AOF文件：

Redis提供了两个命令行程序redis-check-aof 和redis-check-dump ，它们可以在系统故障发生之后，检查AOF文件和快照文件的状态，并在有需要的情况下对文件进行修复。
1)如果用户在运行redis-check-aof 程序时给定了 -fix 参数，那么程序将对AOF文件进行修复。程序修复AOF文件的方法非常简单：它会扫描给定的AOF 文件，寻找不正确或者不完整的命令，当发现第一个出错命令的时候，程序会删除出错的命令以及位于出错命令之后的所有命令，只保留那些位于出错命令之前的正确命令。在大多数情况下，被删除的都是AOF 文件末尾的不完整的写命令。
2)目前并没有办法可以修复出错的快照文件。尽管发现快照文件首个出现错误的地方是有可能的，但因为快照文件本身经过了压缩，而出现在快照文件中间的错误有可能会导致快照文件的剩余部分无法被读取。因此，用户最好为重要的快照文件保留多个备份，并在进行数据恢复时，通过计算快照文件的SHAl散列值和SHA256散列值来对内容进行验证。

更换故障主服务器

假设A、B两台机器都运行着Redis，其中机器A的Redis为主服务器，而机器B的Redis为从服务器。此时机器A出现了故障，因此用户决定将机器C用作新的主服务器。有以下两种方式：

1）首先向机器B发送一个SAVE命令，让它创建一个新的快照文件，接着将这个快照文件发送给机器C，并在机器C上面启动Redis 。最后，让机器B成为机器C的从服务器。(因为机器B 原本就是一个从服务器，所以我们的客户端不能对它进行写人，并且在机器B执行快照操作之后，我们的客户端也不会与其他试图对机器B进行写入的客户端产生竞争条件。)
2）将从服务器B升级（turn）为主服务器，并为升级后的主服务器创建从服务器C