[TOC] # 同时出现RDB和AOF是冲突呢？还是协作？ ~~~ 答案：是协作，不会冲突!那么是如何协作，首先加载哪一个文件呢？ 进行测试，生成dump.rdb和appendonly.aof文件，然后在appendonly.aof使文件最后随便加入一些东西，使文件出错，然后重新启动redis服务，发现服务没有启动成功！那么就可以知道首先加载的是aof文件，使用redis-check-aof 工具修复aof文件，重新启动，发现启动成功！ 总结：两者可以共存，但是首先启动找的是aof。 ~~~ # 重启时将按照以下优先级恢复数据到内存 ~~~ 如果只配置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重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。 # 相关配置 ~~~ 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：不同步 ~~~ # 重写是什么？ 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