[TOC] # 问题 ## RDB可以搞定备份恢复的事情，为什么还会出现AOF？ 答案：这个问题的答案可以参看，上面说的Redis持久化之RDB备份方式保存数据中的RDB的缺点。 也就是使用RDB进行保存时候，如果Redis服务器发送故障，那么会丢失最后一次备份的数据！ AOF出现试着来解决这个问题！ ## 同时出现RDB和AOF是冲突呢？还是协作？ 答案：是协作，不会冲突!那么是如何协作，首先加载哪一个文件呢？ 进行测试，生成dump.rdb和appendonly.aof文件，然后在appendonly.aof使文件最后随便加入一些东西，使文件出错，然后重新启动redis服务，发现服务没有启动成功！那么就可以知道首先加载的是aof文件，使用redis-check-aof 工具修复aof文件，重新启动，发现启动成功！ 总结：两者可以共存，但是首先启动找的是aof。 ## 当redis服务器挂掉时，重启时将按照以下优先级恢复数据到内存 如果只配置AOF,重启时加载AOF文件恢复数据； 如果同时 配置了RBD和AOF,启动是只加载AOF文件恢复数据; 如果只配置RBD,启动是讲加载dump文件恢复数据。 恢复时需要注意，要是主库挂了不能直接重启主库，否则会直接覆盖掉从库的AOF文件，一定要确保要恢复的文件都正确才能启动，否则会冲掉原来的文件。 >如何修复：redis-check-aof –fix appendonly.aof # Redis的AOF是什么？ 官网-AOF中文：http://www.redis.cn/topics/persistence.html 以日志的形式来记录每个写操作（读操作不记录），将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。 # Redis配置文件redis.conf中关于AOF相关配置 ~~~ ############################## 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 # The name of the append only file (default: "appendonly.aof") appendfilename "appendonly.aof" # 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 # 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 # 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 # An AOF file may be found to be truncated at the end during the Redis # startup process, when the AOF data gets loaded back into memory. # This may happen when the system where Redis is running # crashes, especially when an ext4 filesystem is mounted without the # data=ordered option (however this can't happen when Redis itself # crashes or aborts but the operating system still works correctly). # # Redis can either exit with an error when this happens, or load as much # data as possible (the default now) and start if the AOF file is found # to be truncated at the end. The following option controls this behavior. # # If aof-load-truncated is set to yes, a truncated AOF file is loaded and # the Redis server starts emitting a log to inform the user of the event. # Otherwise if the option is set to no, the server aborts with an error # and refuses to start. When the option is set to no, the user requires # to fix the AOF file using the "redis-check-aof" utility before to restart # the server. # # Note that if the AOF file will be found to be corrupted in the middle # the server will still exit with an error. This option only applies when # Redis will try to read more data from the AOF file but not enough bytes # will be found. aof-load-truncated yes ~~~ appendonly yes //启用 aof 持久化方式 appendfilename appendonly.aof //保存命令的文件 # appendfsync always //每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用。 appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐 # appendfsync no //完全依赖 os，性能最好,持久化没保证 ## 默认AOF没有开启 appendonly no #如果要开启，改为yes 启动：修改为yes，启动，这里要注意的是启动的目录和保存aof文件目录是否一致！查看目录命令(config get dir)，这一点在上一篇RDB中讲过 修复：使用redis-check-aof –fix 进行修复 恢复：重启redis然后重新加载 ## 默认名称 ~~~ appendonlyfilename appendonly.aof ~~~ ## 三种appendfsysnc：同步策略 ~~~ #always：同步持久化，每次发生数据变更会立即记录到磁盘，性能较差到数据完整性比较好 everysec：出厂的默认推荐，异步同步，每秒记录一次 #no：不同步 ~~~ # 重写（rewrite） （查看Linux服务器命令-free内存， df磁盘），时间换空间的思想在里面！ ## 重写是什么？ AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof！ aof文件的重写，就是把文件中内容，逆化成命令存储。 比如：10次 incr age 转成 set age 14 一条命令 可以执行手动重写：bgrewriteaof ## 重写原理 > AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)， > 遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件， > 而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似 ## 触发机制 Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。默认64M。 --看触发机制配置，知道公司实力！ # 优点 每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好 每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失 不同步：appendfsync no 从不同步 # 缺点 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同 # 总结 客户端--->命令请求--->服务器 ------->网络协议格式的命令内容-->AOF文件 * AOF 文件是一个只进行追加的日志文件 * Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写 * AOF文件有序地保存了对数据库执行所有写入操作，这些写入操作作为redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松 * 对于相同的数据集来说，AOF文件的体积通常大于RDB文件的体积，根据所使用的fsync策略，AOF的速度可能会慢于RDB