AOF是什么
-
AOF(Append Only File):以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
-
AOF保存的是
appendonly.aof
文件,在配置文件中可以配置文件保存的名称 -
AOF开启后,不过你是做什么操作,只要是写操作,都会自动记录在
appendonly.aof
,所以FLUSHALL
操作也会被记录,当Redis执行FLUSHALL
操作时,AOF会进行记录,导致下次打开读取appendonly.aof
执行操作时,会执行FLUSHALL
,导致没有导入数据
AOF启动/修复/恢复
AOF的appendonly.aof
和RDB的dump.rdb
可以同时存在被Redis读取的同一个目录下,但是Redis会先去读取appendonly.aof
,然后再去读取dump.rdb
启动
修改redis.conf,appendonly
改为yes
恢复
redis重新启动后会重新加载appendonly.aof
恢复数据,appendonly.aof
文件要在Redis启动目录(config get dir)
修复
如果appendonly.aof
文件损坏,在redis安装目录下有一个redis-check-aof
可以修复appendonly.aof
文件,可以把appendonly.aof
文件里面不符合语法规则的语句给删掉,命令:redis-check-aof --fix [AOF备份文件名,默认为appendonly.aof]
在redis.conf配置文件中的位置 APPEND ONLY MODE
appendonly
:代表AOF持久化是否开启,yes
代表开启,no
代表关闭,默认关闭
############################## APPEND ONLY MODE ###############################
# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.
appendonly no
appendfilename
:代表aof
备份文件的文件名
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"
appendfsync
:代表备份策略
always
:同步持久化每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好everysec
:出厂默认推荐,异步操作,每秒记录 如果一秒内宕机,有数据丢失no
:不同步
# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".
# appendfsync always
appendfsync everysec
# appendfsync no
rewrite 是什么
- AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集.可以使用命令
bgrewriteaof
重写原理
- AOF文件持续增长而过大时,会
fork
出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进程的内存中数据,每条记录有一条的Set语句。重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似
触发机制
- Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次
rewrite
后大小的一倍且文件大于64M
时触发
no-appendfsync-on-rewrite
:重写时是否可以运用Appendfsync,用默认no
即可,保证数据安全性
# When the AOF fsync policy is set to always or everysec, and a background
# saving process (a background save or AOF log background rewriting) is
# performing a lot of I/O against the disk, in some Linux configurations
# Redis may block too long on the fsync() call. Note that there is no fix for
# this currently, as even performing fsync in a different thread will block
# our synchronous write(2) call.
#
# In order to mitigate this problem it's possible to use the following option
# that will prevent fsync() from being called in the main process while a
# BGSAVE or BGREWRITEAOF is in progress.
#
# This means that while another child is saving, the durability of Redis is
# the same as "appendfsync none". In practical terms, this means that it is
# possible to lose up to 30 seconds of log in the worst scenario (with the
# default Linux settings).
#
# If you have latency problems turn this to "yes". Otherwise leave it as
# "no" that is the safest pick from the point of view of durability.
no-appendfsync-on-rewrite no
触发机制配置
auto-aof-rewrite-percentage
:设置重写的基准值,上次rewrite后大小的倍率
auto-aof-rewrite-min-size
:设置重写的基准值,AOF文件的大小
# Automatic rewrite of the append only file.
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
#
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
#
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
优势
- 每修改同步:appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
- 每秒同步:appendfsync everysec 异步操作,每秒记录 如果一秒内宕机,有数据丢失
- 不同步:appendfsync no 从不同步
劣势
- 相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb
- aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同
总结
- AOF文件时一个只进行追加的文件
- Redis可以在AOF文件体积变得过大时,自动地在后台对AOF文件进行重写
- AOF文件有序地保存了对数据库执行的所有写入操作,这些写入操作以Redis协议的个数保存,因此AOF文件的内容非常容易被人读懂,对文件的分析也很轻松
- 对于相同的数据集来说,AOF文件的体积通常要大于RDB文件的体积
- 根据所使用的fsync策略,AOF速度可能会慢于RDB