Redis 备份与恢复：RDB 文件与 AOF 文件的使用

好的，各位观众，各位技术爱好者，各位深夜还在撸码的“码农”们，大家好！我是你们的老朋友，江湖人称“Bug终结者”的编程专家。今天，咱们不聊高大上的架构，也不谈深奥的算法，咱们就来聊聊Redis这个“内存数据库界的闪电侠”的备份与恢复。

想象一下，你辛辛苦苦积攒了一堆数据，结果服务器突然宕机，数据全没了！那感觉，就像你精心打理的菜园子，一夜之间被猪拱了，心痛啊！所以，数据备份和恢复，是每个Redis使用者必须掌握的“保命技能”。

今天，咱们就来手把手地教大家如何使用Redis的RDB文件和AOF文件来进行备份和恢复，让你的数据“安如磐石”，再也不怕“猪拱菜园子”了！

第一部分：RDB文件：Redis的“快照”

首先，我们来认识一下RDB文件，它就像给你的Redis数据库拍了一张“快照”，记录了某个时间点Redis的所有数据。

1. 什么是RDB？

RDB，全称Redis Database，就是Redis数据库的“快照文件”。它是一个压缩的二进制文件，包含了某个时间点Redis的所有数据。

你可以把RDB文件想象成一个“时光胶囊”，把Redis数据库在某个时间点的状态完整地保存下来。当你想回到那个时间点时，只需要把这个“时光胶囊”打开，就能恢复到当时的状态。

2. RDB的优点和缺点

任何事物都有两面性，RDB也不例外。

• 优点：

  • 体积小： RDB文件通常比AOF文件小得多，更便于存储和传输。
  • 恢复速度快： RDB文件是二进制文件，恢复速度比AOF文件快得多。
  • 适合备份： RDB文件适合用于定期备份，可以用来恢复到数据库的历史状态。

• 缺点：

  • 数据丢失： RDB是定时备份，如果在两次备份之间发生服务器宕机，那么这段时间内的数据就会丢失。
  • 实时性差： RDB不是实时备份，不能保证数据的实时性。

3. 如何生成RDB文件？

Redis提供了两种生成RDB文件的方式：

• SAVE命令： 这是一个阻塞命令，会阻塞Redis服务器的所有请求，直到RDB文件生成完成。所以，在生产环境中，尽量避免使用SAVE命令。
• BGSAVE命令： 这是一个异步命令，Redis会fork一个子进程来生成RDB文件，不会阻塞Redis服务器的请求。这是推荐的生成RDB文件的方式。

举个栗子🌰：

在Redis客户端输入：

BGSAVE

然后，Redis会告诉你：

Background saving started

这意味着Redis已经开始在后台生成RDB文件了。

4. RDB文件的配置

Redis的配置文件(redis.conf)中，有很多关于RDB的配置项：

• save ： 这个配置项定义了自动生成RDB文件的条件。例如：

  save 900 1   # 900秒内，如果至少有1个key发生变化，则生成RDB文件
  save 300 10  # 300秒内，如果至少有10个key发生变化，则生成RDB文件
  save 60 10000 # 60秒内，如果至少有10000个key发生变化，则生成RDB文件

  你可以根据自己的需求，配置多个save选项。

• stop-writes-on-bgsave-error： 这个配置项决定了当BGSAVE命令出错时，Redis是否停止写入操作。如果设置为yes，则当BGSAVE命令出错时，Redis会停止写入操作，以防止数据不一致。
• rdbcompression： 这个配置项决定了RDB文件是否进行压缩。默认值为yes，表示进行压缩。
• rdbchecksum： 这个配置项决定了RDB文件是否进行校验。默认值为yes，表示进行校验。
• dir： 这个配置项定义了RDB文件的存储目录。
• dbfilename： 这个配置项定义了RDB文件的文件名。

表格总结RDB配置：

配置项	描述	默认值
save <seconds> <changes>	定义自动生成 RDB 文件的条件，例如：save 900 1 表示 900 秒内如果至少有 1 个 key 发生变化，则生成 RDB 文件。可以配置多个 save 选项。	无
stop-writes-on-bgsave-error	当 BGSAVE 命令出错时，是否停止写入操作。设置为 yes 可以防止数据不一致。	yes
rdbcompression	是否对 RDB 文件进行压缩。设置为 yes 可以减小文件大小，但会增加 CPU 消耗。	yes
rdbchecksum	是否对 RDB 文件进行校验。设置为 yes 可以在加载 RDB 文件时检查文件是否损坏。	yes
dir	RDB 文件和 AOF 文件的存储目录。	./
dbfilename	RDB 文件的文件名。	dump.rdb

第二部分：AOF文件：Redis的“日记本”

接下来，我们来认识一下AOF文件，它就像Redis的“日记本”，记录了Redis服务器执行的每一条写命令。

1. 什么是AOF？

AOF，全称Append Only File，就是Redis的“只追加文件”。它记录了Redis服务器执行的每一条写命令（包括SET、HSET、DEL等）。

你可以把AOF文件想象成一个“流水账”，记录了Redis数据库的所有写操作。当你想恢复数据时，只需要把这个“流水账”重新执行一遍，就能恢复到最新的状态。

2. AOF的优点和缺点

• 优点：

  • 数据安全： AOF是实时备份，可以保证数据的安全，即使服务器宕机，最多只会丢失最后一次写操作的数据。
  • 实时性好： AOF是实时备份，可以保证数据的实时性。

• 缺点：

  • 体积大： AOF文件通常比RDB文件大得多，占用更多的存储空间。
  • 恢复速度慢： AOF文件是文本文件，恢复速度比RDB文件慢得多。

3. 如何开启AOF？

在Redis的配置文件(redis.conf)中，找到以下配置项：

appendonly no

把no改为yes，即可开启AOF：

appendonly yes

4. AOF的配置

Redis的配置文件(redis.conf)中，有很多关于AOF的配置项：

• appendfsync： 这个配置项定义了AOF文件的写入策略。有三种可选值：

  • always： 每次写命令都同步写入AOF文件。这是最安全的策略，但性能最差。
  • everysec： 每秒钟同步写入AOF文件。这是一个折中的策略，既保证了数据的安全，又兼顾了性能。
  • no： 由操作系统决定何时写入AOF文件。这是性能最好的策略，但数据最不安全。

  推荐使用everysec策略。

• auto-aof-rewrite-percentage： 这个配置项定义了AOF文件自动重写的触发条件。当AOF文件的大小超过上一次重写后大小的百分之多少时，会自动触发AOF重写。
• auto-aof-rewrite-min-size： 这个配置项定义了AOF文件自动重写的最小大小。当AOF文件的大小小于这个值时，不会自动触发AOF重写。

表格总结AOF配置：

配置项	描述	默认值
appendonly	是否开启 AOF 持久化。	no
appendfilename	AOF 文件的文件名。	appendonly.aof
appendfsync	AOF 文件的写入策略。always 表示每次写入都同步到磁盘，everysec 表示每秒同步一次，no 表示由操作系统决定何时同步。建议设置为 everysec。	everysec
auto-aof-rewrite-percentage	AOF 文件自动重写的触发条件。当 AOF 文件的大小超过上一次重写后大小的百分之多少时，会自动触发 AOF 重写。	100
auto-aof-rewrite-min-size	AOF 文件自动重写的最小大小。当 AOF 文件的大小小于这个值时，不会自动触发 AOF 重写。	64mb
aof-load-truncated	是否允许加载被截断的 AOF 文件。设置为 yes 可以在 AOF 文件损坏时尝试恢复部分数据。	yes
aof-use-rdb-preamble	在AOF重写时，是否使用RDB格式作为AOF文件的前缀。可以加快重启速度	yes

5. AOF重写

随着时间的推移，AOF文件会越来越大，因为它记录了所有的写命令，包括很多冗余的命令。为了减小AOF文件的大小，Redis提供了AOF重写的功能。

AOF重写是指Redis会fork一个子进程，读取Redis数据库中的所有数据，然后把这些数据以最简洁的方式写入一个新的AOF文件，替换掉原来的AOF文件。

你可以把AOF重写想象成整理你的“流水账”，把重复的、无用的记录删除，只保留最重要的记录。

AOF重写可以手动触发，也可以自动触发。

• 手动触发： 在Redis客户端输入：

  BGREWRITEAOF

  然后，Redis会告诉你：

  Background append only file rewriting started

  这意味着Redis已经开始在后台进行AOF重写了。

• 自动触发： 通过配置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size来自动触发AOF重写。

第三部分：Redis的备份与恢复实战

现在，我们已经了解了RDB文件和AOF文件，接下来，我们来实战一下Redis的备份与恢复。

1. RDB备份与恢复

• 备份：

  1. 使用BGSAVE命令生成RDB文件。
  2. 把RDB文件复制到安全的地方，例如：云存储、备份服务器等。

• 恢复：

  1. 停止Redis服务器。
  2. 把备份的RDB文件复制到Redis的RDB文件存储目录(由dir和dbfilename配置项决定)。
  3. 启动Redis服务器。

2. AOF备份与恢复

• 备份：

  1. 开启AOF功能。
  2. 把AOF文件复制到安全的地方，例如：云存储、备份服务器等。

• 恢复：

  1. 停止Redis服务器。
  2. 把备份的AOF文件复制到Redis的AOF文件存储目录(由dir和appendfilename配置项决定)。
  3. 启动Redis服务器。

3. RDB与AOF的选择

那么，在实际应用中，我们应该选择RDB还是AOF呢？

• 如果对数据安全要求不高，可以只使用RDB。 RDB的优点是体积小、恢复速度快，适合用于定期备份。
• 如果对数据安全要求高，可以使用AOF。 AOF的优点是数据安全、实时性好，适合用于实时备份。
• 如果对数据安全要求很高，可以同时使用RDB和AOF。 这种方式可以兼顾RDB的体积小、恢复速度快和AOF的数据安全、实时性好的优点。当Redis服务器重启时，会优先使用AOF文件来恢复数据。

第四部分：最佳实践与注意事项

最后，我们来总结一下Redis备份与恢复的最佳实践与注意事项：

• 定期备份： 无论是RDB还是AOF，都要定期备份，以防止数据丢失。
• 异地备份： 把备份文件存储在不同的地点，以防止灾难发生。
• 监控备份： 监控备份的执行情况，确保备份成功。
• 测试恢复： 定期测试恢复过程，确保备份文件可用。
• 选择合适的备份策略： 根据自己的需求，选择合适的备份策略。

总结：

今天，我们一起学习了Redis的备份与恢复，了解了RDB文件和AOF文件，以及如何使用它们来进行备份和恢复。希望大家能够掌握这些“保命技能”，让你的数据“安如磐石”，再也不怕“猪拱菜园子”了！

记住，数据安全无小事，备份恢复要做好！

好了，今天的分享就到这里，感谢大家的观看！

😄希望这篇文章能帮助大家更好地理解Redis的备份与恢复！如果觉得有用，请点赞、评论、分享哦！👍