Redis：持久化（persistence）

来自Wikioe
跳到导航 跳到搜索


持久化

参考：http://redis.io/topics/persistence

数据持久化：即将数据不同的手段做持久性保存。
   如：放在磁盘（而非内存）就是一种持久化，不会因电脑关闭或重启而丢失数据。

Redis 的数据存储在内存中，内存是瞬时的，如果 linux 宕机或重启，又或者 Redis 崩溃或重启，所有的内存数据都会丢失。


为解决这个问题，Redis 提供了多种不同级别的持久化方式：

  1. RDB 持久化（类比于“物理日志”）：可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
  2. AOF 持久化（类比于“逻辑日志”）：记录服务器执行的所有写操作命令。
    • 在服务器启动时，通过重新执行这些命令来还原数据集。
    • AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。


Redis 还可以同时使用 AOF 持久化和 RDB 持久化。

    在这种情况下，当 Redis 重启时，它会优先使用 AOF 文件来还原数据集，因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。

RDB（Redis Database）

Redis Database（RDB），就是在指定的时间间隔内将内存中的数据集快照（snapshot）写入磁盘，数据恢复时将快照文件直接再读到内存。

RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。
  • 在默认情况下，Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。
  • 可以设置 Redis 在“ N 秒内数据集至少有 M 个改动”时自动保存一次数据集；也可以调用 SAVE 或者 BGSAVE 来手动开始保存操作。


运作方式

当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作：

  1. Redis 调用 fork()，同时拥有父进程和子进程。
  2. 子进程将数据集写入到一个临时 RDB 文件中。
  3. 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。
  • 这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益。


优缺点

总而言之，RDB 更适合于数据备份、转移、恢复，但可能有数据丢失。

优点：

  • RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
  • RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
  • RDB 非常适合用于进行备份：比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
  • RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心。

缺点：

  • 快照不包含丢失执行快照以后更改的数据，所以恢复时可能有数据丢失；
  • 快照过程可能影响 Redis 服务：由于需要经常操作磁盘，RDB 会经常 fork() 出一个子进程，在数据集比较庞大时， fork() 会非常耗时，并且可能会影响 Redis 暂停服务一段时间（millisecond 级别）。
    • 虽然 AOF 重写也需要进行 fork()，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。


附：配置项说明

修改配置文件“redis.conf”即可： 

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 10000

# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes

# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes

# The filename where to dump the DB
dbfilename dump.rdb

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./

其中：

  1. “save <seconds> <changes>”：设置持久化条件“在<seconds>秒内，修改了<changes>次，则进行一次磁盘持久化”；（如上配置，可以多个组合使用）
  2. “dbfilename”：设置 RDB 的文件名，默认文件名为“dump.rdb”；
  3. “dir”：指定 RDB 和 AOF 文件的目录

AOF（Append-only File）

Append-only File（AOF），每当 Redis 执行一个改变数据集的命令时，这个命令就会被追加到 AOF 文件的末尾。

当 Redis 重启时，它通过执行 AOF 文件中所有的命令来恢复数据。
  • AOF 文件有序地保存了对数据库执行的所有写入操作，这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，对文件进行分析（parse）也很轻松。


运作方式

AOF 重写和 RDB 创建快照一样，都巧妙地利用了写时复制机制。

以下是 AOF 重写的执行步骤：

  1. Redis 执行 fork()，现在同时拥有父进程和子进程。
  2. 子进程开始将新 AOF 文件的内容写入到临时文件。
  3. 对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾：这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
  4. 当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
  5. 现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。
整个重写操作是绝对安全的：因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。


AOF 重写

AOF 文件的重写就是对文件内容的整理，将一些命令进行优化，从而可以让文件体积变小；

因为 AOF 的运作方式是不断地将命令追加到文件的末尾，所以随着写入命令的不断增加，AOF 文件的体积也会变得越来越大。

举个例子， 如果你对一个计数器调用了 100 次 INCR ，那么仅仅是为了保存这个计数器的当前值，AOF 文件就需要使用 100 条记录（entry）。
然而在实际上，只使用一条 SET 命令已经足以保存计数器的当前值了，其余 99 条记录实际上都是多余的。

为了处理这种情况，Redis 支持一种有趣的特性：可以在不打断服务客户端的情况下，对 AOF 文件进行重建（rebuild）：

执行 BGREWRITEAOF 命令：Redis 将生成一个新的 AOF 文件，这个文件包含重建当前数据集所需的最少命令。
Redis 2.2 需要自己手动执行 BGREWRITEAOF 命令； Redis 2.4 则可以自动触发 AOF 重写， 具体信息请查看 2.4 的示例配置文件。


AOF 有多耐久？

“appendfsync”配置项，可以设置 Redis 多久才将数据 fsync 到磁盘一次。

有三个选项：

  1. “always”：每次执行写入都会执行同步；（更慢、更安全）
  2. “everysec”：每秒执行一次同步操作；（兼顾速度和安全性）【默认】
    • 速度和使用 RDB 持久化差不多；
    • 在故障时只会丢失 1 秒钟的数据。
  3. “no”：不主动进行同步操作，而是完全交由操作系统来做（即每30秒一次）；（更快、更不安全）
总是 fsync 的策略在实际使用中非常慢，即使在 Redis 2.0 对相关的程序进行了改进之后仍是如此 —— 频繁调用 fsync 注定了这种策略不可能快得起来。


如果 AOF 文件出错了，怎么办？

服务器可能在程序正在对 AOF 文件进行写入时停机，如果停机造成了 AOF 文件出错（corrupt），那么 Redis 在重启时会拒绝载入这个 AOF 文件，从而确保数据的一致性不会被破坏。

AOF 文件是一个只进行追加操作的日志文件（append only log），因此对 AOF 文件的写入不需要进行 seek，即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等），redis-check-aof 工具也可以轻易地修复这种问题。

当发生这种情况时， 可以用以下方法来修复出错的 AOF 文件：

  1. 为现有的 AOF 文件创建一个备份。
  2. 使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。 
    $ redis-check-aof --fix
  3. （可选）使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。
  4. 重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。


优缺点

总而言之，AOF 能更好地保证数据完整，但在速度和文件体积上不如 RDB。

优点：

  • AOF 持久化使 Redis 变得非常耐久（much more durable）：
    • 如策略为“每秒钟 fsync 一次”时，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。
  • Redis 可以在后台对 AOF 文件进行自动重写。
  • AOF 文件错误时可以轻易修复。（redis-check-aof）
  • AOF 文件易于分析：
    • 比如，如果不小心执行了 FLUSHALL 命令，但只要 AOF 文件未被重写，那么只要停止服务器，移除 AOF 文件末尾的 FLUSHALL 命令，并重启 Redis，就可以将数据集恢复到 FLUSHALL 执行之前的状态。

缺点：

  • 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
  • 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB。
    在一般情况下，每秒 fsync 的性能依然非常高，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快，即使在高负荷之下也是如此。不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。
  • AOF 在过去曾经发生过这样的 bug：因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。（举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug）测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集，并通过重新载入这些数据来确保一切正常。虽然这种 bug 在 AOF 文件中并不常见，但是对比来说，RDB 几乎是不可能出现这种 bug 的。


附：配置项说明

修改配置文件“redis.conf”即可： 

############################## APPEND ONLY MODE ###############################

# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.

appendonly no

# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"

# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".

# appendfsync always
appendfsync everysec
# appendfsync no

# When the AOF fsync policy is set to always or everysec, and a background
# saving process (a background save or AOF log background rewriting) is
# performing a lot of I/O against the disk, in some Linux configurations
# Redis may block too long on the fsync() call. Note that there is no fix for
# this currently, as even performing fsync in a different thread will block
# our synchronous write(2) call.
#
# In order to mitigate this problem it's possible to use the following option
# that will prevent fsync() from being called in the main process while a
# BGSAVE or BGREWRITEAOF is in progress.
#
# This means that while another child is saving, the durability of Redis is
# the same as "appendfsync none". In practical terms, this means that it is
# possible to lose up to 30 seconds of log in the worst scenario (with the
# default Linux settings).
#
# If you have latency problems turn this to "yes". Otherwise leave it as
# "no" that is the safest pick from the point of view of durability.
no-appendfsync-on-rewrite no

# Automatic rewrite of the append only file.
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
#
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
#
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# An AOF file may be found to be truncated at the end during the Redis
# startup process, when the AOF data gets loaded back into memory.
# This may happen when the system where Redis is running
# crashes, especially when an ext4 filesystem is mounted without the
# data=ordered option (however this can't happen when Redis itself
# crashes or aborts but the operating system still works correctly).
#
# Redis can either exit with an error when this happens, or load as much
# data as possible (the default now) and start if the AOF file is found
# to be truncated at the end. The following option controls this behavior.
#
# If aof-load-truncated is set to yes, a truncated AOF file is loaded and
# the Redis server starts emitting a log to inform the user of the event.
# Otherwise if the option is set to no, the server aborts with an error
# and refuses to start. When the option is set to no, the user requires
# to fix the AOF file using the "redis-check-aof" utility before to restart
# the server.
#
# Note that if the AOF file will be found to be corrupted in the middle
# the server will still exit with an error. This option only applies when
# Redis will try to read more data from the AOF file but not enough bytes
# will be found.
aof-load-truncated yes

其中：

  1. “appendonly”：启用/关闭 AOF 持久化；【默认no】
  2. “appendfilename”：指定 AOF 文件名，默认文件名为“appendonly.aof”
  3. “dir”：（公用RDB配置的“dir”配置）指定 RDB 和 AOF 文件的目录；
  4. “appendfsync”：配置向 AOF 文件写命令数据的策略：
    • “no”：不主动进行同步操作，而是完全交由操作系统来做（即每30秒一次），比较快但不是很安全；
    • “always”：每次执行写入都会执行同步，慢一些但是比较安全；
    • “everysec”：每秒执行一次同步操作，比较平衡，介于速度和安全之间；【默认】
  5. “auto-aof-rewrite-percentage”：当目前 AOF 文件大小超过上一次重写时的 AOF 文件大小的百分之多少时会再次进行重写；
    • （如果之前没有重写，则以启动时的 AOF 文件大小为依据）
  6. “auto-aof-rewrite-min-size”：允许重写的最小 AOF 文件大小；（一般配置较大，几个 G）

RDB 与 AOF

RDB 和 AOF，应该用哪一个？

  1. 如果想达到足以媲美 PostgreSQL 的数据安全性，应该同时使用两种持久化功能。
  2. 如果非常关心数据，但仍然可以承受数分钟以内的数据丢失，那么可以只使用 RDB 持久化。
  3. 并不推荐只使用 AOF 持久化。
    因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快，除此之外，使用 RDB 还可以避免之前提到的 AOF 程序的 bug。

RDB 和 AOF 之间的相互作用

  1. 在版本号大于等于 2.4 的 Redis 中，BGSAVE 执行的过程中，不可以执行 BGREWRITEAOF。反过来说，在 BGREWRITEAOF 执行的过程中，也不可以执行 BGSAVE。
    • 这可以防止两个 Redis 后台进程同时对磁盘进行大量的 I/O 操作。
    • 如果 BGSAVE 正在执行，并且用户显示地调用 BGREWRITEAOF 命令，那么服务器将向用户回复一个 OK 状态，并告知用户，BGREWRITEAOF 已经被预定执行：一旦 BGSAVE 执行完毕，BGREWRITEAOF 就会正式开始。
  2. 当 Redis 启动时， 如果 RDB 持久化和 AOF 持久化都被打开了，那么程序会优先使用 AOF 文件来恢复数据集，因为 AOF 文件所保存的数据通常是最完整的。

怎么从 RDB 持久化切换到 AOF 持久化？

在 Redis 2.2 或以上版本，可以在不重启的情况下，从 RDB 切换到 AOF ：

  1. 为最新的 dump.rdb 文件创建一个备份。
  2. 将备份放到一个安全的地方。
  3. 执行以下两条命令： 
    # 开启了 AOF 功能
redis-cli> CONFIG SET appendonly yes

# 关闭 RDB 功能
redis-cli> CONFIG SET save ""
    • 开启了 AOF 功能：Redis 会阻塞直到初始 AOF 文件创建完成为止，之后 Redis 会继续处理命令请求， 并开始将写入命令追加到 AOF 文件末尾。
    • 关闭 RDB 功能：这一步是可选的，如果你愿意的话，也可以同时使用 RDB 和 AOF 这两种持久化功能。
  4. 确保命令执行之后，数据库的键的数量没有改变。
  5. 确保写命令会被正确地追加到 AOF 文件的末尾。
  6. 别忘了在 redis.conf 中打开 AOF 功能：否则的话，服务器重启之后，之前通过 CONFIG SET 设置的配置就会被遗忘，程序会按原来的配置来启动服务器。

数据备份与恢复

Redis 对于数据备份是非常友好的，因为你可以在服务器运行的时候对 RDB 文件进行复制：RDB 文件一旦被创建，就不会进行任何修改。当服务器要创建一个新的 RDB 文件时，它先将文件的内容保存在一个临时文件里面，当临时文件写入完毕时，程序才使用 rename(2) 原子地用临时文件替换原来的 RDB 文件。

这也就是说，无论何时，复制 RDB 文件都是绝对安全的。

以下是我们的建议：

  1. 创建一个定期任务（cron job），每小时将一个 RDB 文件备份到一个文件夹，并且每天将一个 RDB 文件备份到另一个文件夹。
  2. 确保快照的备份都带有相应的日期和时间信息，每次执行定期任务脚本时，使用 find 命令来删除过期的快照：比如说，你可以保留最近 48 小时内的每小时快照，还可以保留最近一两个月的每日快照。
  3. 至少每天一次，将 RDB 备份到你的数据中心之外，或者至少是备份到你运行 Redis 服务器的物理机器之外。

手动备份命令

Redis 的 SAVE 和 BGSAVE 命令用于创建当前数据库的备份： 

  1. redis 127.0.0.1:6379> SAVE 
OK
    • 同步保存（会阻塞所有客户端）；
  2. 127.0.0.1:6379> BGSAVE
Background saving started
    • 异步（Asynchronously）保存。
  • 操作后，会产生 RDB 快照文件。

恢复数据

如果需要恢复数据，只需将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可。

  • 当 Redis 启动时，如果 RDB 持久化和 AOF 持久化都被打开了，那么程序会优先使用 AOF 文件来恢复数据集，因为 AOF 文件所保存的数据通常是最完整的。


获取 redis 目录可以使用 CONFIG 命令，如下所示： 

redis 127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/usr/local/redis/bin"

容灾备份

Redis 的容灾备份基本上就是对数据进行备份，并将这些备份传送到多个不同的外部数据中心。

容灾备份可以在 Redis 运行并产生快照的主数据中心发生严重的问题时，仍然让数据处于安全状态。
取自“http://wiki.eijux.com/index.php?title=Redis：持久化（persistence）&oldid=4731”