redis 通过aof日志恢复_Redis AOF 持久化方式

AOF 详解

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程

AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

从配置文件了解AOF

打开 redis.conf 文件，找到 APPEND ONLY MODE 对应内容

1 redis 默认关闭，开启需要手动把no改为yes

2 指定本地数据库文件名，默认值为 appendonly.aof

3 指定更新日志条件

解说：

4 配置重写触发机制

解说：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。

根据AOF文件恢复数据

正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。AOF的优先级高于RDB。

AOF的重写机制

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重

写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结

果转化成最终结果数据对应的指令进行记录。

AOF重写作用

降低磁盘占用量，提高磁盘利用率

提高持久化效率，降低持久化写时间，提高IO性能

降低数据恢复用时，提高数据恢复效率

AOF重写规则

进程内已超时的数据不再写入文件

忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令

如del key1、 hdel key2、srem key3、set key4 111、set key4 222等

对同一数据的多条写命令合并为一条命令

如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。

为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

AOF重写触发机制

auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb

触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。

手动重写：

127.0.0.1:6379>BGREWRITEAOF

Background append only file rewriting started127.0.0.1:6379>info

# Server

redis_version:4.0.12redis_git_sha1:00000000redis_git_dirty:0redis_build_id:470df41a36d1ac6e

redis_mode:standalone

os:Linux3.10.0-1062.12.1.el7.x86_64 x86_64

arch_bits:64multiplexing_api:epoll

atomicvar_api:atomic-builtin

AOF 的优缺点

优点：数据的完整性和一致性更高

缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。

操作演示

[root@itdragon bin]# vim appendonly.aof

appendonly yes

[root@itdragon bin]# ./redis-server redis.conf

[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379

127.0.0.1:6379> keys *(empty list orset)127.0.0.1:6379> setkeyAOf valueAof

OK127.0.0.1:6379>FLUSHALL

OK127.0.0.1:6379>SHUTDOWN

not connected>QUIT

[root@itdragon bin]# ./redis-server redis.conf

[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379

127.0.0.1:6379> keys *

1) "keyAOf"

127.0.0.1:6379>SHUTDOWN

not connected>QUIT

[root@itdragon bin]# vim appendonly.aof

fjewofjwojfoewifjowejfwf

[root@itdragon bin]# ./redis-server redis.conf

[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379Could not connect to Redis at127.0.0.1:6379: Connection refused

not connected>QUIT

[root@itdragon bin]# redis-check-aof --fix appendonly.aof'x 3e: Expected prefix'*', got:'AOF analyzed: size=92, ok_up_to=62, diff=30This will shrink the AOFfrom 92 bytes, with 30 bytes, to 62bytes

Continue? [y/N]: y

Successfully truncated AOF

[root@itdragon bin]# ./redis-server redis.conf

[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379

127.0.0.1:6379> keys *

1) "keyAOf"

第一步：修改配置文件，开启AOF持久化配置。

第二步：重启Redis服务，并进入Redis 自带的客户端中。

第三步：保存值，然后模拟数据丢失，关闭Redis服务。

第四步：重启服务，发现数据恢复了。(额外提一点：有教程显示FLUSHALL 命令会被写入AOF文件中，导致数据恢复失败。我安装的是redis-4.0.2没有遇到这个问题)。

第五步：修改appendonly.aof，模拟文件异常情况。

第六步：重启 Redis 服务失败。这同时也说明了，RDB和AOF可以同时存在，且优先加载AOF文件。

第七步：校验appendonly.aof 文件。重启Redis 服务后正常。

补充点：aof 的校验是通过 redis-check-aof 文件，那么rdb 的校验是不是可以通过 redis-check-rdb 文件呢？？？

总结

Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。

RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。

Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。

AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。

Redis 针对 AOF文件大的问题，提供重写的瘦身机制。

若只打算用Redis 做缓存，可以关闭持久化。

若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。 对数据非常敏感，建议使用默认的AOF持久化方案

部分参考了：https://www.cnblogs.com/itdragon/p/7906481.html