Redis持久化——RDB与AOF

Redis持久化——RDB与AOF

RDB

Redis是内存数据库，如果不将内存中的数据库状态保存到硬盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化功能。

在指定的时间间隔内，将内存中的数据集快照写入磁盘，也就是Snapshot（快照），它恢复时是将快照文件直接读到内存里。

Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，等待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能会丢失。

rdb保存的文件是dump.rdb，都是可以在配置文件的快照中进行配置。

rdb触发机制

################################ SNAPSHOTTING  ################################
save 900 1
save 300 10
save 60 10000

1、save的规则满足的情况下，会自动触发rdb规则

2、执行flushall 命令。也会触发rdb规则

3、正常结束redis进程的时候，也会产生rdb文件，如果强制结束进程（kill -9），则不会产生

备份就自动生成一个dump.rdb文件

如何恢复rdb文件？

1、只需要将rdb文件放在redis配置文件中指定的目录即可， redis启动的时候会自动检查dump.rdb文件，恢复其中的数据。

备注：redis默认的配置几乎就已经足够了，但是多了解一些并无坏处。

• rdb优点：

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

• rdb缺点：

  • 需要一定的时间间隔来进行操作。如果redis意外宕机，最后一次修改的数据就没有了。
  • 创建fork进程的时候，会占用一定的内存空间。

所以在生产环境中，我们会将dump.rdb进行备份。

AOF

将我们所有的命令都记录下来(history)，恢复的时候就把这个文件全部执行一遍。

以日志的形式来记录每个除了读以外的操作，将redis执行过程中的所有指令（读的指令除外）记录下来，只允许追加文件，不可改写文件，redis启动之初会读取该文件重新构建数据。换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次，以完成数据的恢复工作。

aof保存的文件是appendonly.aof，AOF默认就是文件的无限追加，文件就会越来越大。

AOF触发机制

################################ SNAPSHOTTING  ################################
# 默认是不开启的，改为yes就开启了aof
appendonly no

# appendfsync always	# 同步开启，文件完整性会更好，消耗CPU性能
appendfsync everysec	# 每秒执行fsync
# appendfsync no		# 不执行fsync，操作系统自己同步数据，速度最快，存在较大的风险。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb	# 文件大小超过64MB，会fork一个新的子进程，来将文件进行重写。

修改配置文件之后，重启redis就生效了，开始每秒对除了查询以外的命令进行保存，并在配置文件中指定的目录下生成appendonly.aof文件。

注意：如果AOF和RDB都开启的话，AOF优先级更高。

如果生成aof或rdb文件出错，redis启动会失败，这时候可以尝试使用redis-check-aof或redis-check-rdb进行修复。

[root@huan bin]# ll
total 46088 
-rwxr-xr-x. 1 root root  6398640 Aug 28 02:31 redis-benchmark
-rwxr-xr-x. 1 root root 11322968 Aug 28 02:31 redis-check-aof
-rwxr-xr-x. 1 root root 11322968 Aug 28 02:31 redis-check-rdb
-rwxr-xr-x. 1 root root  6726080 Aug 28 02:31 redis-cli
-rw-r--r--. 1 root root    83435 Aug 28 02:53 redis.conf
lrwxrwxrwx. 1 root root       12 Aug 28 02:31 redis-sentinel -> redis-server
-rwxr-xr-x. 1 root root 11322968 Aug 28 02:31 redis-server

使用演示

./redis-check-aof --fix appendonly.aof
This shrink the AOF from 185 bytes, with 46 bytes, to 139 bytes
Continue? [y/N]: y
Successfully truncated AOF

有可能会把错误附近的正常数据也给删掉，导致一小部分数据丢失。

• AOF优点

  • 每一次修改都同步，文件的完整性会更加好。
  • 每秒同步一次，可能会丢失一秒的数据
  • 从不同步的情况下，效率是最高的

• AOF缺点：

  • 相对于数据文件来说，AOF大小远远大于RDB，修复的速度也比RDB慢
  • AOF运行效率也要比RDB慢

所以redis默认使用的持久化方式是RDB。在主从复制中，rdb在从机上面就是备用来使用的，不消耗主机的资源。AOF几乎不使用。

扩展：

1. RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储

2. AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。

3. 只做缓存，如果只希望数据在服务器运行的时候存在，也可以不使用任何持久化

4. 同时开启两种持久化方式

   • 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
   • RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。

5. 性能建议

   • 因为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 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时宕机，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的RDB文件，载入较新的那个，微博就是这种架构。