Redis persistence mechanism - AOF

AOF: Append Only File

RDB rdb lost file was last backed up, but in fact it does not matter, in fact, may be negligible, after all, cache, just be more, but if the pursuit of integrity of the data, it would consider the use of the AOF.

AOF Features

1. In the form of a log record of the write operation to the user request. Read operations are not recorded, because the write operation will be kept stored.
2. File additional form rather than a modified form.
3. redis recovery of aof fact, the implementation of additional file read from the beginning to the end of the write operation.

Advantage

1. AOF more durable, it can back up in seconds as a unit level, if a problem occurs, it will only lose the last second of data, greatly increasing the reliability and data integrity. So AOF can be backed up once per second, using the fsync operation.
2. Append to log log form, if the disk is full, will perform redis-check-aof tool
3. When the data is too big when, redis can automatically rewrite aof in the background. When redis continue to append to the log file when the old go, rewrite is very safe and does not affect the read and write operations of the client.
4. AOF log contains all write operations, it will be easier to resolve redis recovery.

Disadvantaged

1. The same data, the same data, AOF than large RDB
2. For different synchronization mechanism, AOF will be slower than the RDB, because AOF per second will be the backup to do a write so relatively speaking it is slightly lower with the RDB. Backup fsync per second is nothing wrong, but if the client every time you do a backup fsync write, then redis performance will drop.
3. AOF happened bug, when data recovery is incomplete data, this appears to AOF would be more fragile and prone to bug, because AOF RDB not so simple, but it generated in order to prevent bug, AOF will not go heavy under the old directive structure, but to do was reconstructed according to the instruction cache data exists, so that a more robust and reliable.

AOF configuration

# AOF 默认关闭，yes可以开启
appendonly no

# AOF 的文件名
appendfilename "appendonly.aof"

# no：不同步
# everysec：每秒备份，推荐使用
# always：每次操作都会备份，安全并且数据完整，但是慢性能差
appendfsync everysec

# 重写的时候是否要同步，no可以保证数据安全
no-appendfsync-on-rewrite no

# 重写机制：避免文件越来越大，自动优化压缩指令，会fork一个新的进程去完成重写动作，新进程里的内存数据会被重写，此时旧的aof文件不会被读取使用，类似rdb
# 当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m，满足两者则触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

In the end still using RDB AOF it?

1. If you can accept cache miss some time, you can use RDB
2. If you compare the data for real-time care, then use the AOF
3. AOF RDB and using persistent binding together do, do RDB cold backup, restore can be done at different times for different versions, AOF do hot standby, with only one second to ensure that data loss. When AOF damage is not available, then RDB and then recover, so do both combined with each other, which means that the recovery will be loaded Redis AOF, if there is a problem AOF will reload RDB, so that to achieve the purpose of hot and cold backups a.