Redis 持久化

RDB(Redis Database)

机制

• 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存里。
• Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
• 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
• 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
• RDB的缺点是最后一次持久化后的数据可能丢失。
• RDB保存的文件为dump.rdb
• Redis默认开启RDB

自动触发RDB

• save的规则满足的情况下，会自动触发RDB规则。
• 指定flashall命令，也会触发RDB规则。
• 退出redis也会触发RDB规则。

创建备份

SAVE

• Redis SAVE 命令用于创建当前数据库的备份。

$ SAVE

实例

$ SAVE
OK

• 该命令将在 Redis 安装目录中创建dump.rdb文件。

BGSAVE

• 创建 Redis 备份文件也可以使用命令 BGSAVE，该命令在后台执行。

实例

127.0.0.1:6379> BGSAVE

Background saving started

恢复数据

• 如果需要恢复数据，只需将备份文件（dump.rdb）移动到 Redis 安装目录并启动服务即可，获取 Redis 目录可以使用 CONFIG 命令，如下所示：

$ CONFIG GET dir
1) "dir"
2) "/usr/local/redis/bin"

• 以上命令 CONFIG GET dir 输出的 Redis 安装目录为 /usr/local/redis/bin

配置

配置项	说明
save <seconds> <changes>Redis 默认配置文件中提供了三个条件**save 900 1 ** save 300 10 save 60 10000分别表示 900 秒（15 分钟）内有 1 个更改，300 秒（5 分钟）内有 10 个更改以及 60 秒内有 10000 个更改	指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
stop-writes-on-bgsave=error yes	持久化如果出错，是否还需要继续工作，默认为yes
rdbcompression yes	指定存储至本地数据库时是否压缩数据，默认为 yes,Redis 采用 LZF 压缩，如果为了节省 CPU 时间，可以关闭该选项，但会导致数据库文件变的巨大
rdbchecksum yes	保存rdb文件时，是否进行错误的校验
dbfilename dump.rdb	指定本地数据库文件名，默认值为 dump.rdb

特点

优点

• 适合大规模的数据恢复。
• 对数据的完整性要求不高。

缺点

• 需要一定的时间间隔进行操作，如果Redis意外宕机，最后一次修改数据不会被保存。
• fork进程时，会占用一定内存空间。

AOF(Append Only File)

• 以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录）
• 只许追加文件但不可以改写文件。
• Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
• AOF保存的是appendonly.aof文件。
• Redis默认关闭AOF，可修改配置文件开启。

修复AOF文件

redis-check-aof --fix

配置

配置项	说明
appendonly no	指定是否在每次更新操作后进行日志记录，Redis 在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失，因为 redis 本身同步数据文件是按上面 save 条件来同步的，所以有的数据会在一段时间内只存在于内存中，默认为 no
appendfilename appendonly.aof	指定更新日志文件名，默认为 appendonly.aof
appendfsync everysec	指定更新日志条件，共有 3 个可选值： no：表示等操作系统进行数据缓存同步到磁盘（快） always：表示每次更新操作后手动调用 fsync(）将数据写到磁盘（慢，安全） everysec：表示每秒同步一次（折中，默认值）
no-appendfsync-on-rewrite no	aof默认为文件的无限追加，可开启rewrite功能避免单文件过大
auto-aof-rewrite-percentage 100	aof文件超过上次rewrite文件大小的指定百分比时触发rewrite
auto-aof.rewrite-min-size 64mb	aof文件超过指定大小时触发rewrite

特点

优点

• 每一次修改都同步，文件的完整性更好。

缺点

• AOF运行运行效率低。

RDB与AOF对比

• RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储。
• AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据， AOF命令以Redis协议追加保存每次写的操作到文件末尾， Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
• 只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化。
• 同时开启两种持久化方式
  • 在这种情况下，当Redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
  • RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢?作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份） ，快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。
• 性能建议
  • 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
  • 如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。
    • 代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
    • 只要硬盘许可，应该尽量减少AOF rewrite的频率， AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
  • 如果不Enable AOF ，仅靠Master-Slave Repllcation实现高可用性也可以，能省掉一大笔10，也减少了rewrite时带来的系统波动，代价是如果Master/slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/slave中的RDB文件，载入较新的那个，微博就是这种架构。