6.4 如何选用持久化方式
6.4.1 对比两种持久化方式
AOF可以设置一秒写一次持久化文件,所以相对RDB而言,这种方式能更好地记录内存数据,从而能更好地达到持久化的效果,且AOF是以"在文件末尾追加"的方式写入数据,所以性能较好.不过AOF持久化的文件一般会大于RDB快照,所以用AOF恢复数据时速度会比RDB要慢
在某些个别场景里,Redis服务器在重启时无法加载AOF持久化文件,从而导致无法恢复数据,这种情况虽然出现的概率很小,但是一旦出现,或许就是灾难性的
某些场景是指:
AOF文件损坏:
如果Redis或宿主机突然崩溃,如电源故障,这可能会导致AOF文件的某些部分不完整或损坏
如果磁盘已满或发生其他文件系统错误,可能会导致AOF文件写入不完整
AOF格式版本不兼容:
如果你尝试使用一个较新版本的Redis加载一个由较旧版本的Redis创建的AOF文件,可能会遇到兼容性问题
文件系统权限问题:
如果Redis进程没有适当的权限来读取AOF文件或其所在的目录,它将无法加载该文件
配置问题:
如果Redis的配置文件中的
appendonly
选项被设置为no
,那么Redis将不会加载AOF文件,即使它存在appendfilename
或dir
配置可能指向了错误的AOF文件或目录
AOF文件过大:
如果AOF文件非常大,Redis在启动时可能需要较长时间来加载它.虽然这并不是一个真正的"无法加载"的情况,但在实际操作中可能会被误解为加载失败
硬件问题:
磁盘故障、损坏的RAM或其他硬件问题可能会影响AOF文件的完整性和可读性
外部因素:
如果有外部进程(例如备份或监控工具)锁定了AOF文件,这可能会干扰Redis读取文件
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重写操作所花费的总时间.单位:秒
Last updated