redis持久化方案之-AOF
AOF方式
介绍:
- 默认情况下Redis没有开启AOF(append only file)方式的持久化
-
开启AOF持久化后每执行一条会更改Redis中的数据的命令,Redis就会将该命令写入硬盘中的AOF文件,这一过程显然会降低Redis的性能,但大部分情况下这个影响是能够接受的,另外使用较快的硬盘可以提高AOF的性能。
-
可以通过修改redis.conf配置文件中的appendonly参数开启
appendonly yes
-
AOF文件的保存位置和RDB文件的位置相同,都是通过dir参数设置的。
dir ./
- 默认的文件名是appendonly.aof,可以通过appendfilename参数修改:
appendfilename appendonly.aof
AOF重写原理(优化AOF文件)
lRedis 可以在 AOF 文件体积变得过大时,自动地在后台对 AOF 进行重写
l重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。
l整个重写操作是绝对安全的,因为 Redis 在创建新 AOF 文件的过程中,会继续将命令追加到现有的 AOF 文件里面,即使重写过程中发生停机,现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕,Redis 就会从旧 AOF 文件切换到新 AOF 文件,并开始对新 AOF 文件进行追加操作。
lAOF 文件有序地保存了对数据库执行的所有写入操作, 这些写入操作以 Redis 协议的格式保存, 因此 AOF 文件的内容非常容易被人读懂, 对文件进行分析(parse)也很轻松
l参数说明
# auto-aof-rewrite-percentage 100 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过,以启动时aof文件大小为准
# auto-aof-rewrite-min-size 64mb 限制允许重写最小aof文件大小,也就是文件大小小于64mb的时候,不需要进行优化
AOF文件损坏以后如何修复
服务器可能在程序正在对 AOF 文件进行写入时停机, 如果停机造成了 AOF 文件出错(corrupt), 那么 Redis 在重启时会拒绝载入这个 AOF 文件, 从而确保数据的一致性不会被破坏。
当发生这种情况时, 可以用以下方法来修复出错的 AOF 文件:
1. 为现有的 AOF 文件创建一个备份。
2. 使用 Redis 附带的 redis-check-aof 程序,对原来的 AOF 文件进行修复。
redis-check-aof --fix
3. 重启 Redis 服务器,等待服务器载入修复后的 AOF 文件,并进行数据恢复。
如何选择RDB和AOF
l 一般来说,如果对数据的安全性要求非常高的话,应该同时使用两种持久化功能。
l 如果可以承受数分钟以内的数据丢失,那么可以只使用 RDB 持久化。
l 有很多用户都只使用 AOF 持久化, 但并不推荐这种方式: 因为定时生成 RDB 快照(snapshot)非常便于进行数据库备份, 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快 。
l 两种持久化策略可以同时使用,也可以使用其中一种。如果同时使用的话, 那么Redis重启时,会优先使用AOF文件来还原数据