6.4 如何选用持久化方式

6.4.1 对比两种持久化方式

AOF可以设置一秒写一次持久化文件,所以相对RDB而言,这种方式能更好地记录内存数据,从而能更好地达到持久化的效果,且AOF是以"在文件末尾追加"的方式写入数据,所以性能较好.不过AOF持久化的文件一般会大于RDB快照,所以用AOF恢复数据时速度会比RDB要慢

在某些个别场景里,Redis服务器在重启时无法加载AOF持久化文件,从而导致无法恢复数据,这种情况虽然出现的概率很小,但是一旦出现,或许就是灾难性的

某些场景是指:

  1. AOF文件损坏:

    • 如果Redis或宿主机突然崩溃,如电源故障,这可能会导致AOF文件的某些部分不完整或损坏

    • 如果磁盘已满或发生其他文件系统错误,可能会导致AOF文件写入不完整

  2. AOF格式版本不兼容:

    • 如果你尝试使用一个较新版本的Redis加载一个由较旧版本的Redis创建的AOF文件,可能会遇到兼容性问题

  3. 文件系统权限问题:

    • 如果Redis进程没有适当的权限来读取AOF文件或其所在的目录,它将无法加载该文件

  4. 配置问题:

    • 如果Redis的配置文件中的appendonly选项被设置为no,那么Redis将不会加载AOF文件,即使它存在

    • appendfilename或dir配置可能指向了错误的AOF文件或目录

  5. AOF文件过大:

    • 如果AOF文件非常大,Redis在启动时可能需要较长时间来加载它.虽然这并不是一个真正的"无法加载"的情况,但在实际操作中可能会被误解为加载失败

  6. 硬件问题:

    • 磁盘故障、损坏的RAM或其他硬件问题可能会影响AOF文件的完整性和可读性

  7. 外部因素:

    • 如果有外部进程(例如备份或监控工具)锁定了AOF文件,这可能会干扰Redis读取文件

  8. AOF文件内部的命令错误:

    • 在某些情况下,AOF文件中的命令可能会引起Redis启动时的错误.例如,一个命令可能引用了一个不存在的键

为了更好地理解和解决加载AOF文件时的问题,可以查看Redis的日志文件.这通常会提供有关为什么Redis无法加载AOF文件的详细信息和错误消息.如果出现问题,你可以使用redis-check-aof工具来检查和修复AOF文件.

相对而言,RDB的快照是二进制文件,所以一般比AOF要小,所以在恢复数据时占优势,而且通过BGSAVE等方式生成快照时,Redis服务器会新创建一个子进程,所以不会影响Redis服务器继续执行命令.不过RDB持久化的缺陷之前也已经提到,即无法即时恢复数据

综合考虑到这两种方式的优缺点,在实际项目里可以同时用到这两种方式,当出现数据误删的情况时,可以用AOF持久化文件来恢复数据,在一般情况下,可以用RDB快照来恢复数据.一旦出现因AOF持久化文件损坏而无法恢复数据的情况,就可以用RDB的方式来恢复数据,最大限度地提升Redis内存数据的安全性

6.4.2 综合使用两种持久化方式

  • step1. 编写配置文件

  • step2. 启动redis-server

  • step3. 写入一些键值对

  • step4. 查看配置文件指定的路径下的文件情况

可以看到,AOF文件和RDB文件同时存在

6.4.3 查看持久化状态的命令

  • INFO persistence:查看持久化相关状态

其中:

  • rdb_last_save_time:上次RDB持久化快照的生成时间

  • aof_enabled:是否启用AOF持久化机制

  • aof_last_write_status:上次AOF同步数据的操作是否成功

  • aof_current_rewrite_time_sec:表示当前AOF重写操作(如果有的话)已经进行的秒数.如果没有AOF重写操作正在进行,该值为-1

  • aof_last_rewrite_time_sec:上一次AOF重写操作所花费的总时间.单位:秒

Previous6.3 RDB持久化机制实战Next第7章 搭建Redis集群

Last updated