Redis的AOF持久化（二）

一 appendfsync说明

为了控制redis服务器在遇到意外停机时丢失的数据量，redis为AOF持久化提供appendfsync选项，这个选项的值可以是always，ererysec或者no，这些值得含义分别是：

always：服务器每写入一个命令，就调用一次fdatasync，将缓冲区里面的命令写入到硬盘里面，在这种模式下，服务器即使遭遇到意外停机，也不会丢失任何自己已经成功执行的命令数据。

ererysec：服务器每一秒钟调用一次fdatasync，将缓冲区里面的命令写入到硬盘里面，在这种模式下，服务器即使遭遇意外停机，最多只丢失一秒钟内的执行命令数据。

no：服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘里面。在这种模式下，服务器遭遇意外停机时，丢失的命令数据是不确定的。

运行速度：always的速度慢，ererysec和no都很快。

默认值：everysec

二 AOF文件的冗余命令

随着服务器不断运行，为了记录数据库发生的变化，服务器会将越来越多的命令写入到AOF文件里面，使得AOF文件的体积不断增大。

为了让AOF文件的大小控制在合理的范围，避免它胡乱增长，redis提供了AOF重写功能，通过这个功能，服务器可以产生一个新的AOF文件：

1 新的AOF文件记录的数据库数据和原有的AOF文件记录的数据库数据完全一样。

2 新的AOF文件会使用尽可能少的命令来记录数据库中的数据，因此新的AOF文件体积通常会比原有的AOF文件的体积要小得多。

3 AOF重写期间，服务器不会被阻塞，可以正常处理客户端发送的命令请求。

三 AOF重写原理

四 触发重写条件

有两种方法可以触发AOF重写：

1 客户端向服务器发送BGREWRITEAOF命令。

2 通过设置配置选项来让服务器自动执行BGREWRITEAOF命令，他们分别是：

auto-aof-rewrite-min-size <size>,触发AOF重写所需要的最小体积：只要在AOF文件的体积大于等于size时。服务器才会考虑是否需要重写AOF，这个选项避免体积过小的AOF文件进行重写

auto-aof-rewrite-percentage <percent>,指定触发重写所需的AOF文件体积百分比：当AOF文件的体积大于auto-aof-rewrite-min-size指定体积，并且超过上一次重写之后的AOF体积的percent%时，就会触发AOF重写。如果服务器刚刚启动不久，还没有进行过AOF重写，那么使用服务器启动时载入的AOF文件的体积来作为基准值。将这个值设置为0，表示关闭自动AOF重写。

例子

auto-aof-rewrite-min-size 64mb

auto-aof-rewrite-percentage 100

第1条规则的意思是：当AOF文件大于64mb之后才考虑进行AOF重写，然后第2条规则的意思是说只有当AOF文件的增量大于100%的时候才进行重写，也就是大一倍的时候才触发。

五 RDB和AOF方式对比

六 补充说明

可以同时使用两种持久化，根据你的需要来判断，还原数据优先使用AOF文件。

所以说Redis数据库安全性比不上SQL数据库的安全性是个误解，当使用always模式运行时，Redis持久化和一般的SQL数据库持久化方式一样的。

七 实战

[root@master ~]# redis-cli
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
[root@master ~]# cd /root
[root@master ~]# ll appendonly.aof
-rw-r--r-- 1 root root 1067 Jan 31 21:04 appendonly.aof