【文档熟肉】Redis持久化

Redis Persistence

Redis 持久化

Redis provides a different range of persistence options:
Redis提供了两种类型持久化操作：

• RDB (Redis Database): The RDB persistence performs point-in-time snapshots of your dataset at specified intervals.
  RDB(Redis Database):RDB持久化是以指定的间隔时间在某个时间点对数据执行快照。

• AOF (Append Only File): The AOF persistence logs every write operation received by the server, that will be played again at server startup, reconstructing the original dataset. Commands are logged using the same format as the Redis protocol itself, in an append-only fashion. Redis is able to rewrite the log in the background when it gets too big.
  AOF (Append Only File):AOF持久化会记录每一次来自于服务器的写操作，这些在服务器重启时会再一次的执行，重新构建原来的数据。写命令会通过仅追加的方式，以Redis命令原本的样式记录下来，Redis在log文件太大时，会在后台重写。

• No persistence: If you wish, you can disable persistence completely, if you want your data to just exist as long as the server is running.
  无持久化：如果你愿意，你完全可以关闭持久化，如果你希望你的数据的存在时间只和服务器的运行时间一样长的话。

• RDB + AOF: It is possible to combine both AOF and RDB in the same instance. Notice that, in this case, when Redis restarts the AOF file will be used to reconstruct the original dataset since it is guaranteed to be the most complete.
  The most important thing to understand is the different trade-offs between the RDB and AOF persistence. Let’s start with RDB:
  RDB+AOF:可以在同一台节点联合使用AOF和RDB。请注意，在这种情况下，当Redis重启时，AOF文件将被用于重新构建初始数据，因为它可以保证最完整(的数据)
  理解RDB和AOF持久化的不同的权衡是很重要的。让我们看下RDB：

RDB advantages

RDB优点

• RDB is a very compact single-file point-in-time representation of your Redis data. RDB files are perfect for backups. For instance you may want to archive your RDB files every hour for the latest 24 hours, and to save an RDB snapshot every day for 30 days. This allows you to easily restore different versions of the data set in case of disasters.
  RDB是一个在某个时间点对Redis数据的紧密的单文件快照。RDB文件用于备份是非常好的。例如，您可能希望在最近的24小时内每小时对RDB文件进行归档，并在30天内每天保存一个RDB快照。它允许你可以很容易的重建不同版本的数据集，以防止发生灾难。

• RDB is very good for disaster recovery, being a single compact file that can be transferred to far data centers, or onto Amazon S3 (possibly encrypted).
  RDB非常适合灾后重新恢复，它是一个紧凑的文件，可以传输到远程数据中心或Amazon S3(可能是加密的)。

• RDB maximizes Redis performances since the only work the Redis parent process needs to do in order to persist is forking a child that will do all the rest. The parent process will never perform disk I/O or alike.
  RDB最大限度地提高了Redis的性能，因为Redis父进程需要做的唯一的工作是为了创建Redis子进程，它将做所有其余的工作。父进程不会处理IO或者类似的工作。

• RDB allows faster restarts with big datasets compared to AOF.
  相比于AOF，RDB在数据集比较大时重启会更快。

• On replicas, RDB supports partial resynchronizations after restarts and failovers.
  在副本上，RDB支持在重新启动和故障转移后的部分重新同步。

RDB disadvantages

RDB缺点

• RDB is NOT good if you need to minimize the chance of data loss in case Redis stops working (for example after a power outage). You can configure different save points where an RDB is produced (for instance after at least five minutes and 100 writes against the data set, you can have multiple save points). However you’ll usually create an RDB snapshot every five minutes or more, so in case of Redis stopping working without a correct shutdown for any reason you should be prepared to lose the latest minutes of data.
  如果你需要最小化数据丢失的方法，以防Redis停止工作(例如停电后)，RDB是不好的。你可以配置不同的保存点来生成RDB（例如在至少五分钟和100次数据集的写操作后，你可以进行多次保存）。但是如果你通常以五分钟甚至更长时间来生成RDB快照的话，当某些情况下Redis因为某些原因，以不正确的方式停止工作时，你要做好失去最近几分钟数据的准备。

• RDB needs to fork() often in order to persist on disk using a child process. fork() can be time consuming if the dataset is big, and may result in Redis stopping serving clients for some milliseconds or even for one second if the dataset is very big and the CPU performance is not great. AOF also needs to fork() but less frequently and you can tune how often you want to rewrite your logs without any trade-off on durability.
  RDB需要经常调用fork()方法来创建子进程，(将数据)持久化到磁盘。如果数据集很大的话，fork()方法可能很耗时，并且导致Redis停止服务客户端若干毫秒，甚至如果数据集非常大的话可能达到一秒，并且CPU性能表现不会很好。AOF也需要调用fork()方法但是频率更低，并且你可以配置你想要多久追加续写一次你的日志，并且在持久化的性能上毫不逊色。

AOF advantages

AOF优点

• Using AOF Redis is much more durable: you can have different fsync policies: no fsync at all, fsync every second, fsync at every query. With the default policy of fsync every second write performances are still great (fsync is performed using a background thread and the main thread will try hard to perform writes when no fsync is in progress.) but you can only lose one second worth of writes.
  使用AOF，Redis的可用性更高：你可以选择不同的fsync策略：从不fsync，每秒fsync，每次查询都fsunc。在默认的每秒fsync策略下，写性能依然很好（fsync是通过后台线程执行的，当没有fsync时，主线程会执行写操作），而且你只用损失一秒钟的写数据。

• The AOF log is an append only log, so there are no seeks, nor corruption problems if there is a power outage. Even if the log ends with an half-written command for some reason (disk full or other reasons) the redis-check-aof tool is able to fix it easily.
  AOF日志是仅追加的日志，所以当出现停电时，不会出现泄露或日志的损坏。甚至当由于某些原因日志结尾出现半行写命令时(磁盘满了或者其他原因)，Redis的检查aof工具也可以很轻松的修复它。

• AOF contains a log of all the operations one after the other in an easy to understand and parse format. You can even easily export an AOF file. For instance even if you’ve accidentally flushed everything using the FLUSHALL command, as long as no rewrite of the log was performed in the meantime, you can still save your data set just by stopping the server, removing the latest command, and restarting Redis again.
  为了更轻松的理解和解析格式，AOF的日志是一个命令接着另一个的。你也可以轻易的导出AOF文件。例如即使你意外的用FLUSHALL命令清除了所有（数据），只要你同时执行没有重写的日志，你依然可以保存你的数据集。你只需要停止服务器，删掉最新的（例如FLUSHAAL）命令，并且重启Redis即可。

AOF disadvantages

AOF缺点

• AOF files are usually bigger than the equivalent RDB files for the same dataset.
  相同大小的数据集下，AOF文件通常要比同等的RDB文件要更大。

• AOF can be slower than RDB depending on the exact fsync policy. In general with fsync set to every second performance is still very high, and with fsync disabled it should be exactly as fast as RDB even under high load. Still RDB is able to provide more guarantees about the maximum latency even in the case of a huge write load.
  由于fsync策略，AOF要比RDB慢。通常来说每秒fsync，表现依然很好，并且fsync可以被关闭，这样即使在高负载的情况下它依然和RDB一样快。当然，即使在写负载的情况下，RDB依然可以提供更大的延迟的保障。

Redis < 7.0
Redis低于7.0版本

• AOF can use a lot of memory if there are writes to the database during a rewrite (these are buffered in memory and written to the new AOF at the end).
  如果在重写期间（这些（数据）已经缓存在了内存中并且最后写在了新的AOF（文件）中），AOF会使用大量内存。

• All write commands that arrive during rewrite are written to disk twice.
  在重写期间，所有的写命令都要到磁盘两次（一次旧AOF一次新AOF文件？）。

• Redis could freeze writing and fsyncing these write commands to the new AOF file at the end of the rewrite.
  在重写的最后，Redis会冻结写操作并且将这些写操作同步到一个新的AOF文件。

Ok, so what should I use?

好的，那我该用哪种（持久化）方式？

The general indication is that you should use both persistence methods if you want a degree of data safety comparable to what PostgreSQL can provide you.
如果你想要你的数据安全程度堪比PostgreSQL的话，通常的建议是你可以同时使用两种持久化方式。

If you care a lot about your data, but still can live with a few minutes of data loss in case of disasters, you can simply use RDB alone.
如果你关心你的数据，但是仍然可以在灾难中忍受几分钟的数据损失，你可以只是用RDB。

There are many users using AOF alone, but we discourage it since to have an RDB snapshot from time to time is a great idea for doing database backups, for faster restarts, and in the event of bugs in the AOF engine.
有许多用户只是用AOF，但是我们不建议这样做，为了更快的重启，以及AOF引擎可能出现的bug，定期的RDB才是数据库备份的好主意。

Note: for all these reasons we’ll likely end up unifying AOF and RDB into a single persistence model in the future (long term plan).
注意：由于这些原因，我们在将来最终可能将AOF和RDB统合成一种持久化模型。

The following sections will illustrate a few more details about the two persistence models.
下面的部分会更加详细的阐述两种持久化模型的细节。

Snapshotting

快照

By default Redis saves snapshots of the dataset on disk, in a binary file called dump.rdb. You can configure Redis to have it save the dataset every N seconds if there are at least M changes in the dataset, or you can manually call the SAVE or BGSAVE commands.
默认的Redis在磁盘中保存数据集的快照，位于一个叫做dump.rdb的二进制文件中。你可以配置Redis，使之至少M次数据集的写操作，每N秒保存一次数据集，或者你可以通过SAVE或者BGSAVE命令手动（保存）。

For example, this configuration will make Redis automatically dump the dataset to disk every 60 seconds if at least 1000 keys changed:
例如，这种配置方式可以在至少1000个key发生变化时，Redis每60秒自动备份数据集到磁盘中。

save 60 1000

This strategy is known as snapshotting.
这种方式叫做快照。

How it works
它（快照）如何工作

Whenever Redis needs to dump the dataset to disk, this is what happens:
每当Redis需要向磁盘中备份数据集时，就会发生如下：

• Redis forks. We now have a child and a parent process.
  Redis调用fork方法（创建子线程）。我们现在拥有一个一个子线程和父线程。

• The child starts to write the dataset to a temporary RDB file.
  这个子线程开始向临时RDB文件中写入数据集（的数据）

• When the child is done writing the new RDB file, it replaces the old one.
  当子线程写完新的RDB文件时，它（新RDB文件）就会取代旧的那个（RDB文件）

This method allows Redis to benefit from copy-on-write semantics.
这种方法支持Redis的写时备份。

Append-only file

仅追加文件

Snapshotting is not very durable. If your computer running Redis stops, your power line fails, or you accidentally kill -9 your instance, the latest data written to Redis will be lost. While this may not be a big deal for some applications, there are use cases for full durability, and in these cases Redis snapshotting alone is not a viable option.
快照的可用性不是非常高。如果你的电脑在运行Redis时停止了，你的电源线断了，或者你意外的杀死了你的节点，最新写入到Redis中的数据会丢失。当然这对一些应用不是大问题，但是一些情况需要很高的稳定性，这些情况下不建议单独使用快照。

The append-only file is an alternative, fully-durable strategy for Redis. It became available in version 1.1.
对Redis来说，仅追加文件是可选的、高可用的策略。在1.1版本后可用。

You can turn on the AOF in your configuration file:
你可以在你的配置文件中打开AOF：

appendonly yes

From now on, every time Redis receives a command that changes the dataset (e.g. SET) it will append it to the AOF. When you restart Redis it will re-play the AOF to rebuild the state.
从现在开始，每次Redis接受到会改变数据集的命令（就是写操作命令啦）都会追加到AOF中。当你重启Redis时它会重新执行AOF，以恢复原来状态。

Since Redis 7.0.0, Redis uses a multi part AOF mechanism. That is, the original single AOF file is split into base file (at most one) and incremental files (there may be more than one). The base file represents an initial (RDB or AOF format) snapshot of the data present when the AOF is rewritten. The incremental files contains incremental changes since the last base AOF file was created. All these files are put in a separate directory and are tracked by a manifest file.
从Redis7.0.0开始，Redis开始使用复合AOF方法。也就是说，最初的原始AOF文件会被分割成基础文件（最多只有一个）和
增量文件（这种可能多余于一个）。基础文件代表当AOF开始重写时，数据的初始快照。增量文件包括最新的AOF文件创建过程中新增的变化。所有这些文件都放进了单独的目录中并且被指针文件记录。

Log rewriting
日志重写

As you can guess, the AOF gets bigger and bigger as write operations are performed. For example, if you are incrementing a counter 100 times, you’ll end up with a single key in your dataset containing the final value, but 100 entries in your AOF. 99 of those entries are not needed to rebuild the current state.
如你所猜测，随着写操作的执行AOF会变得越来越大。例如，如果你改变一个值100次，你结束时数据集中只包括一个key和最终的value，但是你的AOF中包括100次命令。其中99次命令对于重构数据都是非必须的。

The rewrite is completely safe. While Redis continues appending to the old file, a completely new one is produced with the minimal set of operations needed to create the current data set, and once this second file is ready Redis switches the two and starts appending to the new one.
重写是安全的。当Redis继续向旧文件追加（命令）时，一个全新的文件会创造出来，它是创造当前数据集所需的操作的最小集合，并且第二个文件就绪时Redis会将第二个转换（为正在使用的）并且向新的文件追加（写命令）。

So Redis supports an interesting feature: it is able to rebuild the AOF in the background without interrupting service to clients. Whenever you issue a BGREWRITEAOF Redis will write the shortest sequence of commands needed to rebuild the current dataset in memory. If you’re using the AOF with Redis 2.2 you’ll need to run BGREWRITEAOF from time to time. Since Redis 2.4 is able to trigger log rewriting automatically (see the example configuration file for more information).
所以Redis支持一项有趣的特性：它可以在不打断对客户端服务的情况下，在后台重新构建AOF文件。无论何时你使用命令BGREWRITEAOF Redis都会在内存中记录构建当前数据集所需要的最短的集合。如果Redis版本为2.2，当你正在使用AOF时，你需要经常（手动）运行（命令）BGREWRITEAOF。从Redis2.4版本开始，它已经可以自动触发日志的重写了（查看更多配置文件的信息）

Since Redis 7.0.0, when an AOF rewrite is scheduled, The Redis parent process opens a new incremental AOF file to continue writing. The child process executes the rewrite logic and generates a new base AOF. Redis will use a temporary manifest file to track the newly generated base file and incremental file. When they are ready, Redis will perform an atomic replacement operation to make this temporary manifest file take effect. In order to avoid the problem of creating many incremental files in case of repeated failures and retries of an AOF rewrite, Redis introduces an AOF rewrite limiting mechanism to ensure that failed AOF rewrites are retried at a slower and slower rate.
从Redis7.0.0开始，当计划执行重写AOF时，Redis父线程会打开一个新的增量AOF文件继续写入。而子线程执行重写逻辑，并且正常一个新的基础AOF文件。Redis会使用临时指针文件去追踪新生成的基础文件和增量文件。当它们都就绪后，Redis会执行自动替换操作，使这个临时指针文件生效。为了避免多次替换失败和尝试重写AOF，导致的新增许多增量文件，Redis引入了一个AOF重写限制机制，以保证失败的AOF重写被限制在一个相当低的比率。

How durable is the append only file?
仅追加文件的可用性如何？

You can configure how many times Redis will fsync data on disk. There are three options:
你可以配置Redis在磁盘上fsync（备份/同步）数据的频率。也就是这些操作：

• appendfsync always: fsync every time new commands are appended to the AOF. Very very slow, very safe. Note that the commands are apended to the AOF after a batch of commands from multiple clients or a pipeline are executed, so it means a single write and a single fsync (before sending the replies).
  一直追加备份：每次新命令都会追加到AOF中。（会导致）速度很慢，（但是）很安全。注意，在执行多个客户端和信道的一系列命令被执行后，命令被追加写进AOF中，它表示单次写操作和单次备份（在发送响应之前）。

• appendfsync everysec: fsync every second. Fast enough (since version 2.4 likely to be as fast as snapshotting), and you may lose 1 second of data if there is a disaster.
  每秒追加备份：每秒都追加备份。相当快速（从2.4版本后几乎和快照（RDB）一样快），而且如果发生灾难你可能只用损失一秒钟的数据。

• appendfsync no: Never fsync, just put your data in the hands of the Operating System. The faster and less safe method. Normally Linux will flush data every 30 seconds with this configuration, but it’s up to the kernel’s exact tuning.
  不追加备份：从不备份，把你的数据（的安全性）放在操作系统的手上。这是一种更加快速但是更不安全的方法。在这个配置下，通常Linux会每30秒清除一次数据，但是它也取决于内核的准确轮换（时间）。

The suggested (and default) policy is to fsync every second. It is both very fast and pretty safe. The always policy is very slow in practice, but it supports group commit, so if there are multiple parallel writes Redis will try to perform a single fsync operation.
建议（也是默认）的策略是每秒备份一次。它兼顾了非常快的速度和不错的安全性。每次写命令都备份的策略在实际应用中会非常慢，但是它也支持批量提交（执行），所以当有多个并行的写操作时，Redis会尝试执行一个单次备份操作。

What should I do if my AOF gets truncated?
如果我的AOF被截断了我该怎么办？

It is possible that the server crashed while writing the AOF file, or that the volume where the AOF file is stored was full at the time of writing. When this happens the AOF still contains consistent data representing a given point-in-time version of the dataset (that may be old up to one second with the default AOF fsync policy), but the last command in the AOF could be truncated. The latest major versions of Redis will be able to load the AOF anyway, just discarding the last non well formed command in the file. In this case the server will emit a log like the following:
有可能在写入AOF文件时服务器崩溃了，或者在写入的同时AOF文件存储的分区满了。当这些发生时，AOF依然包括一个给定时间点版本的数据集的连续数据（它可能会是老版本的，取决于一秒钟一次备份的默认AOF备份策略），但是AOF中最新的命令会被截断。Redis最新的主版本会立即加载AOF，只是需要抛弃文件中格式损坏的命令。这种情况下，服务器会产生下列形式的日志：

* Reading RDB preamble from AOF file...
* Reading the remaining AOF tail...
 # !!! Warning: short read while loading the AOF file !!!
 # !!! Truncating the AOF at offset 439 !!!
 # AOF loaded anyway because aof-load-truncated is enabled

You can change the default configuration to force Redis to stop in such cases if you want, but the default configuration is to continue regardless of the fact the last command in the file is not well-formed, in order to guarantee availability after a restart.
如果你想要使Redis停止上述例子中的情况，你可以改变默认的配置，因为默认配置会继续不管文件中格式损坏的最新命令，以保证重启后的（数据）可用。

Older versions of Redis may not recover, and may require the following steps:
老版本的Redis可能不会恢复，并且可能要求（进行）如下步骤：

Make a backup copy of your AOF file.
制作一个你的AOF文件的复制备份。

Fix the original file using the redis-check-aof tool that ships with Redis:
根据Redis的提示使用Redis检查AOF工具，修复原始文件：

$ redis-check-aof --fix

Optionally use diff -u to check what is the difference between two files.
可以使用diff -u来检查两个文件中有什么区别。

Restart the server with the fixed file.
使用修复后的文件重启服务器。

What should I do if my AOF gets corrupted?
如果我的AOF损坏了我该怎么办？

If the AOF file is not just truncated, but corrupted with invalid byte sequences in the middle, things are more complex. Redis will complain at startup and will abort:
如果AOF文件没有被截断，但是被非法的字节序列在（文件）中段损坏了，事情就变得更加复杂了。
Redis会在开启时警告并且终止（运行）。

* Reading the remaining AOF tail...
# Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix <filename>

The best thing to do is to run the redis-check-aof utility, initially without the --fix option, then understand the problem, jump to the given offset in the file, and see if it is possible to manually repair the file: The AOF uses the same format of the Redis protocol and is quite simple to fix manually. Otherwise it is possible to let the utility fix the file for us, but in that case all the AOF portion from the invalid part to the end of the file may be discarded, leading to a massive amount of data loss if the corruption happened to be in the initial part of the file.
最佳的应对手段是运行Redis修复AOF程序，不带–fix操作去启动，在遇到了问题后，在文件中跳过（非法部分的）指针，并且有可能手动的修复文件：AOF使用和Redis协议同样的格式，并且手动修复相当简单。此外对我们来说也有方法修复文件，但是在那些情况下，所有AOF从非法部分到文件结束的部分都会被废弃，如果这种损坏情况发生，将导致大量的数据损失。

How it works
它的工作原理
Log rewriting uses the same copy-on-write trick already in use for snapshotting. This is how it works:
日志重写使用的是和已经在快照中使用的相同的技术，写时备份技术。下面是它工作的原理：

Redis >= 7.0
Redis版本大于等于7.0

Redis forks, so now we have a child and a parent process.
Redis创建线程，所以现在我们有了一个子线程和父线程。

The child starts writing the new base AOF in a temporary file.
子线程开始向临时文件中写入，作为新的基础AOF文件。

The parent opens a new increments AOF file to continue writing updates. If the rewriting fails, the old base and increment files (if there are any) plus this newly opened increment file represent the complete updated dataset, so we are safe.
父线程会打开一个新的增量AOF文件，以继续写入更新。如果重写失败，旧的基础文件和增量文件（如果有的话）加上新打开的增量文件代表了完整的写入数据集，所以我们（的数据）仍然是安全的。

When the child is done rewriting the base file, the parent gets a signal, and uses the newly opened increment file and child generated base file to build a temp manifest, and persist it.
当子线程完成了重写基础文件，父线程会收到信号，并且使用新打开的增量文件和子线程生成的基础文件去构建一个暂时的指针，并且将之存储。

Profit! Now Redis does an atomic exchange of the manifest files so that the result of this AOF rewrite takes effect. Redis also cleans up the old base file and any unused increment files.
好消息！现在Redis可以做到指针文件的自动储存，所以AOF重写会（自动）生效。Redis也会清楚旧基础文件和任何不再使用的增量文件。

Redis < 7.0
Redis版本小于7.0

Redis forks, so now we have a child and a parent process.
Redis创建线程，所以现在我们有了一个子线程和父线程。

The child starts writing the new AOF in a temporary file.
子线程开始向临时文件中写入，作为新的基础AOF文件。

The parent accumulates all the new changes in an in-memory buffer (but at the same time it writes the new changes in the old append-only file, so if the rewriting fails, we are safe).
父线程会将所有新变化在内存中缓存上（但是同时它会向旧的仅追加文件中写入新的变化，因此如果重写失败，我们（的数据）依然是安全的）。

When the child is done rewriting the file, the parent gets a signal, and appends the in-memory buffer at the end of the file generated by the child.
当子线程重写文件结束后，父线程会收到一个信号，并且将内存中缓存（的写命令）追加到子线程生成的文件的末尾。

Profit! Now Redis atomically renames the new file onto the old one, and starts appending new data into the new file.
好消息！现在Redis可以自动为新文件命名为旧文件的（名字），并且向新文件开始追加新数据。

How I can switch to AOF, if I’m currently using dump.rdb snapshots?
如果我当前正在使用快照dump.rdb，我该如何切换到AOF？

There is a different procedure to do this in version 2.0 and later versions, as you can guess it’s simpler since Redis 2.2 and does not require a restart at all.
对于2.0版本和以后的版本，有不同步骤，如你所猜从Redis 2.2以后变得更简单并且不需要重启了。

Redis >= 2.2
Redis版本大于2.2

• Make a backup of your latest dump.rdb file.
  备份你的最新的dump.rdb文件

• Transfer this backup to a safe place.
  将备份转移到一个安全的地方。

• Issue the following two commands:
  输入下面两条命令

 - redis-cli config set appendonly yes
 - redis-cli config set save ""

• Make sure that your database contains the same number of keys it contained before the switch.
  确保你的数据库包含相比转换之前的（数据库）相同数量的key。

• Make sure that writes are appended to the append only file correctly.
  确保所有的写操作被正确的追加到了仅追加文件中。

The first CONFIG command enables the Append Only File persistence.
第一个配置命令是开启AOF持久化。

The second CONFIG command is used to turn off snapshotting persistence. This is optional, if you wish you can take both the persistence methods enabled.
第二个命令是关掉快照持久化。这是可选的，如果你愿意你可以同时开启两种持久化。

IMPORTANT: remember to edit your redis.conf to turn on the AOF, otherwise when you restart the server the configuration changes will be lost and the server will start again with the old configuration.
重点：记住编辑你的redis.conf开启AOF，否则当你重启服务器时，配置的改变会丢失，并且服务器会以旧配置启动。

Redis 2.0
Redis 2.0版本

• Make a backup of your latest dump.rdb file.
  备份你的最新的dump.rdb文件

• Transfer this backup into a safe place.
  将备份转移到一个安全的地方。

• Stop all the writes against the database!
  停止数据库的所有写操作！

• Issue a redis-cli BGREWRITEAOF. This will create the append only file.
  在Redis客户端输入BGREWRITEAOF。它会创造仅追加文件。

• Stop the server when Redis finished generating the AOF dump.
  当Redis生成AOF文件结束 时停止服务器。

• Edit redis.conf end enable append only file persistence.
  编辑redis.conf的结尾，开启仅追加文件的持久化。

• Restart the server.
  重启服务器。

• Make sure that your database contains the same number of keys it contained before the switch.
  确保你的数据库包含相比转换之前的（数据库）相同数量的key。

• Make sure that writes are appended to the append only file correctly.
  确保所有的写操作被正确的追加到了仅追加文件中。

Interactions between AOF and RDB persistence

AOF和RDB持久化之间的交互

Redis >= 2.4 makes sure to avoid triggering an AOF rewrite when an RDB snapshotting operation is already in progress, or allowing a BGSAVE while the AOF rewrite is in progress. This prevents two Redis background processes from doing heavy disk I/O at the same time.
Redis大于2.4的版本会在RDB快照进行期间，保证避免AOF的重写，或者在AOF重写期间避免BGSAVE。因为它会导致2个Redis后台线程在同一时间对磁盘造成严重IO压力。

When snapshotting is in progress and the user explicitly requests a log rewrite operation using BGREWRITEAOF the server will reply with an OK status code telling the user the operation is scheduled, and the rewrite will start once the snapshotting is completed.
当快照在正在进行时，并且用户通过命令BGREWRITEAOF明确要求进行（AOF）日志重写操作，服务器会回复OK状态码，告诉用户该操作已计划安排上，并且快照一旦结束重写就会立即开始。

In the case both AOF and RDB persistence are enabled and Redis restarts the AOF file will be used to reconstruct the original dataset since it is guaranteed to be the most complete.
在AOF和RDB持久化都开启的情况下，Redis重启时，AOF文件会被用于重新构建初始数据集，这是因为它能够最大程度的保证（数据的）完整性。

Backing up Redis data

备份Redis数据

Before starting this section, make sure to read the following sentence: Make Sure to Backup Your Database. Disks break, instances in the cloud disappear, and so forth: no backups means huge risk of data disappearing into /dev/null.
在这一部分开始之前，务必已经阅读了下面的说明：确保备份你的数据库。磁盘损坏，云（存储）服务器的节点的消失，等等：没有备份会意味着数据消失到/dev/null的巨大风险。

Redis is very data backup friendly since you can copy RDB files while the database is running: the RDB is never modified once produced, and while it gets produced it uses a temporary name and is renamed into its final destination atomically using rename(2) only when the new snapshot is complete.
从你在数据库运行时可以复制RDB文件开始，Redis的数据备份非常友好：RDB从创建以后从不修改，并且会在一开始创建时使用一个临时名字，最终在新的快照完成时，会自动重命名为rename(2)。

This means that copying the RDB file is completely safe while the server is running. This is what we suggest:
这意味着在服务器运行时复制RDB文件是完全安全的。下面是我们的建议：

• Create a cron job in your server creating hourly snapshots of the RDB file in one directory, and daily snapshots in a different directory.
  在你的服务器中创建一个cron脚本，在一个目录中保存每小时一次的快照，并且在另一个目录中保存每天一次的快照。

• Every time the cron script runs, make sure to call the find command to make sure too old snapshots are deleted: for instance you can take hourly snapshots for the latest 48 hours, and daily snapshots for one or two months. Make sure to name the snapshots with date and time information.
  每次cron脚本运行时，记得使用查找命令以确保删除过于老旧的快照：例如你对于每小时一次的快照，可以保存最近48小时（的快照），并且每天一次的快照，保存最近一或两个月（的快照）。确保以日期和时间信息命名快照。

• At least one time every day make sure to transfer an RDB snapshot outside your data center or at least outside the physical machine running your Redis instance.
  每天至少一次，确保将RDB快照传输到数据中心之外，或者至少是你的正在运行的Redis节点的物理机之外。

If you run a Redis instance with only AOF persistence enabled, you can still copy the AOF in order to create backups. The file may lack the final part but Redis will be still able to load it (see the previous sections about truncated AOF files).
如果你在运行一个Redis节点时，只开启AOF持久化，你依然可以复制AOF以进行备份。这个文件可能会缺少最后的部分，但是Redis依然能够加载它（查看之前关于截断AOF文件的章节）。

Since Redis 7.0.0, all the base, increment and manifest files will be placed in a directory determined by the appendddirname configuration. So the best suggestion is to copy the entire directory when backing up AOF persistence.
从Redis7.0.0后，一项叫做appendddirname的配置项决定的目录中放置了所有的基础文件、增量文件、指针文件。所以在备份AOF持久化时，最好的方法就是复制整个目录。

Disaster recovery

灾后恢复

Disaster recovery in the context of Redis is basically the same story as backups, plus the ability to transfer those backups in many different external data centers. This way data is secured even in the case of some catastrophic event affecting the main data center where Redis is running and producing its snapshots.
在Redis中，灾后恢复基本上和备份是同样的流程，加之将这些备份传输到多个不同的附加的数据中心的能力。这种方法会保证数据安全，即使在某些情况下，一些灾难性的事情在Redis运行时和产生快照时影响了主数据中心。

Since many Redis users are in the startup scene and thus don’t have plenty of money to spend we’ll review the most interesting disaster recovery techniques that don’t have too high costs.
由于许多Redis用户在起步阶段，因此没有许多的资金来使用，我们审阅了最感兴趣且不需要花费太多的灾后恢复技术。

• Amazon S3 and other similar services are a good way for implementing your disaster recovery system. Simply transfer your daily or hourly RDB snapshot to S3 in an encrypted form. You can encrypt your data using gpg -c (in symmetric encryption mode). Make sure to store your password in many different safe places (for instance give a copy to the most important people of your organization). It is recommended to use multiple storage services for improved data safety.
  Amazon S3和其他类似的技术对于补充你的灾后恢复系统是很好的方式。可以很简单的将你每天和每小时的RDB快照以加密的形式传输到S3。你可以通过使用gpg -c来解密你的数据（一种对称加密手段）。确保在多个不同的安全渠道存储了你的密码（例如给你的组织中最重要的人复制一份）。推荐使用多种复合存储技术来保证你的数据安全。

• Transfer your snapshots using SCP (part of SSH) to far servers. This is a fairly simple and safe route: get a small VPS in a place that is very far from you, install ssh there, and generate an ssh client key without passphrase, then add it in the authorized_keys file of your small VPS. You are ready to transfer backups in an automated fashion. Get at least two VPS in two different providers for best results.
  使用SCP（SSH的一部分）来将你的快照传输到远程服务器中。这是一种相当简单和安全的常规方法：在一个距离你非常遥远的地方获得一个VPS，在那里建立SSH，并且不使用密码生成一个ssh 客户端key，然后把它加入到你的小VPS的认证key文件中。你已经可以通过这种相当流行的自动化传输方案来备份了。如果想获得最好的结果，最好从2个不同的提供者那里或者至少2个VPS。

It is important to understand that this system can easily fail if not implemented in the right way. At least make absolutely sure that after the transfer is completed you are able to verify the file size (that should match the one of the file you copied) and possibly the SHA1 digest if you are using a VPS.
如果系统没有正确安装，很容易就失败，理解这些是很重要的。至少要绝对保证完整传输后，你能够验证文件大小（也就是必须能够和你复制的那个文件匹配上）并且你使用的一个VPS可能是SHA1摘要。

You also need some kind of independent alert system if the transfer of fresh backups is not working for some reason.
你还需要一些独立的告警系统，以防传输新备份文件由于某些原因停止工作。

参考文档：
[1]，Redis官方文档 Redis Persistence