Redis持久化--AOF

一，介绍

1. 什么是AOF？

   • 以日志的形式来记录每一个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件不许改写文件，redis重启之处会会读取该文件重新构建数据，inother words，如果redis重启就会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

二，AOF配置

1. appendonly 默认是no yes才是执行AOF持久化
2. appendfilename “aof备份的文件名.aof”
3. Appendfsync
   • Always:同步持久化每次发生数据变更就会被立即记录到磁盘，性能较差，但数据完整性比较差
   • Everysec：出厂默认推荐，异步操作，每秒记录，如果一秒内宕机，有数据丢失
   • No
4. No-appendfsync-on-rewrite：重写时是否可以运用Appendfsync，默认no，保证数据安全性。
5. Auto-aof-rewrite-min-size：64mb 设置重写时的基准值 工作中可能会写到3G
6. Auto-aof-rewrite-min-percentage：100 设置重写时的基准值的百分比

三，AOF启动/修复/恢复

1. 正常启动/恢复

   • 启动：appendonly no改为yes
   • 将有数据的aof文件复制一份保存到对应目录（复制到备机上）
   • 恢复：重启Redis然后重新加载

2. 异常恢复

   • 如果生成的aof备份文件被损坏怎么办？
     • 运行redis-check-aof --fix 被损坏的.aof备份的文件名重启即可
     • 补充：redis-check-dump修复被损坏的dump文件

四，Rewrite

1. 什么是Rewrite？

   • AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

2. 重写原理

   • AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename），遍历新进程中的内存中数据，每条记录有一条的set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

3. 触发机制

   • Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

4. 优点（可以灵活的修改配置）

   • 每秒同步：appendfsync always 同步持久化，每次发生数据变化就会被立即记录到磁盘，性能较差，但数据完整性比较好
   • 每秒修改同步：appendfsync everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失
   • 不同步：appendfsync no 从不同步

5. 缺点

   • 相同数据集的数据而言aof文件的体积通常大于rdb文件，恢复速度慢于rdb
   • Aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同
   • Aof 会越来越大，磁盘占有量会越来越大

五，补充

1. 同时开启RDB和AOF时Redis启动先找哪个备份文件

   • 找aof文件
   • 如果aof文件被损坏，redis服务会启动失败。

2. AOF文件是一个只进行追加的日志文件

3. Redis可以在AOF文件体积变得过大时，自动的在后台对AOF进行重写

4. AOF文件有序的保存了对数据执行的写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松