6.redis持久化(AOF)

575 阅读5分钟

AOF持久化介绍

AOF持久化(Append Only File)以日志的形式来记录每个写操作,将redis执行过的所有写指令记录下来(读操作不记录,类似备份数据库数据时记录写操作的sql文件),只许追加AOF文件但不可以改写文件。

redis启动之初会读取该文件重新构建数据。换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF持久化配置

AOF持久化数据默认保存在一个名为appendonly.aof的AOF文件中,该文件位于dir所配置的目录下,持久化相关配置文件信息位于redis.confAPPEND ONLY MODE模块下。redis更多配置信息参考:redis配置文件

#是否开启AOF持久化,默认关闭
appendonly no
#配置AOF文件名称,默认名称为appendonly.aof
appendfilename "appendonly.aof"
#持久化策略always模式,总是写入aof文件,并完成磁盘同步,性能较差但数据完整性比较好
# appendfsync always
#持久化策略everysec模式,每一秒写入aof文件,并完成磁盘同步,如果1秒内宕机,会丢失最后一秒的数据,是相对于always和no模式的这种办法
appendfsync everysec
#持久化策略no模式,写入aof文件,不等待磁盘同步,速度最快
# appendfsync no
#重写aof文件时,是否可以运用appendfsync配置,用默认no即可,保证数据的安全性
no-appendfsync-on-rewrite no
#当aof文件大小超过上一次重写的aof文件大小的指定百分比时进行重写,即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。
auto-aof-rewrite-percentage 100
#允许重写的最小aof文件大小
auto-aof-rewrite-min-size 64mb

注:bgrewriteaof机制,在一个子进程中进行aof的重写,从而不阻塞主进程对其余命令的处理,同时解决了aof文件过大问题。现在问题出现了,同时在执行bgrewriteaof操作和主进程写aof文件的操作,两者都会操作磁盘,而bgrewriteaof往往会涉及大量磁盘操作,这样就会造成主进程在写aof文件的时候出现阻塞的情形,现在no-appendfsync-on-rewrite参数出场了。如果该参数设置为no,是最安全的方式,不会丢失数据,但是要忍受阻塞的问题。如果设置为yes呢?这就相当于将appendfsync设置为no,这说明并没有执行磁盘操作,只是写入了缓冲区,因此这样并不会造成阻塞(因为没有竞争磁盘),但是如果这个时候redis挂掉,就会丢失数据。丢失多少数据呢?在linux的操作系统的默认设置下,最多会丢失30s的数据。因此,如果应用系统无法忍受延迟,而可以容忍少量的数据丢失,则设置为yes。如果应用系统无法忍受数据丢失,则设置为no 此处参考:www.cnblogs.com/ExMan/p/102…

恢复数据

  1. 开启AOF方式的持久化。 appendonly yes
  2. 配置AOF文件名称,默认名称为appendonly.aofappendfilename "appendonly.aof"
  3. 配置从哪个目录下的AOF文件中恢复数据,默认位置为当前开启redis服务的路径。 dir ./
  4. 将有数据的appendfilename 名称的AOF文件放到dir目录下,当redis服务启动时,自动执行aof文件记录的命令来恢复数据。

修复AOF文件

当AOF文件异常导致数据恢复失败时,可通过执行 redis-check-aof --fix <AOF文件名称> 命令来恢复该文件。

优点

  1. 即使在最恶劣的情况,appendfsync不同策略保证了不会丢失超过2秒的数据。
  2. 当aof文件超过一定阈值时,会触发重写机制,确保文件不会太大。

缺点

  1. 相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb。
  2. aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同。
  3. aof即使有重写机制,但aof文件重写和redis数据恢复有可能带来阻塞问题。

总结

  1. AOF文件时一个只进行追加的日志文件,redis可以在AOF文件体积变得过大时,自动地在后台AOF进行重写。
  2. AOF文件有序地保存了对数据库执行的所有写入操作,这些写入操作以redis协议的格式保存,因此AOF文件的内容非常容易被人读懂,对文件进行分析也很轻松。
  3. 对于相同的数据集来说,AOF文件的体积通常要大于RDB文件的体积,根据所使用的fsync 策略,AOF的速度可能会慢于RDB。

RDB和AOF的选择

因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1这条规则。

如果Enalbe AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

如果不Enable AOF ,仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个。新浪微博就选用了这种架构。