复述的RDB方式不能做到妙计持久化,但是AOF方式可以做到。如果数据比较重要,丢失会造成严重的后果,那么RDB方式明显不合适,要用到AOF的方式.aof方式和mysql的binlog日志有些像,都只记录新增,修改,删除的操作。不同的是,复述,会每隔一段时间后,会对AOF文件进行重写,降低AOF文件的大小。
<强>
appendonly:是否开启AOF持久化方式,默认是不。如想开启则改为是的。
dir: AOF文件存放目录
appendfilename: AOF文件名
appendfsync: AOF同步方式,有三个值,分别如下:
- <李>
总是:每写入一个命令时就同步,数据的安全性最高,但性能差
<李>everysec:每秒同步,默认的方式,性能高、安全性也还行
<李>没有:同步操作交给操作系统,数据的安全性最差。
auto-aof-rewrite-percentage, auto-aof-rewrite-min-size这两个配置是和AOF重写机制相关的,只有同时满足这两个条件才会触发重写机制。
auto-aof-rewrite-min-size是表示重写时,文件大小必须必这个值要大,默认值是64 mb
auto-aof-rewrite-percentage表示目前文件大小比上次重写后的文件大小大这么多才行。
<强>
复述的AOF重写机制有手动触发和自动触发两种方式。手动触发即输入bgrewriteof命令。自动触发即满足上述所有的两个条件。
为什么重写能缩小文件体积,有几种情况:
- <李>
过期的键及已删除的键将不会再记录
<李>许多单个操作可以有一个操作来完成,比如lpush, lpush b,重写后就是lpush b。
下面看看aof重写流程
- <李>
执行bgrewriteof命令
<李>主进程叉出一个子进程
<李>原有的aof机制继续运行,同时,也将新的命令写入到aof_rewrite_buf中
<李>子进程生成新的aof文件
<李>通知父进程,新的aof文件已经生成成功,将aof_rewrite_buf中的命令追加到新的aof文件中,用新的aof文件替换旧的aof文件。
<李>完成以上步骤后,aof重写就完成了。
注意,如果一个服务器上面有多个复述,服务,那么最好将他们重写的时间分隔开,防止io及cpu竞争过大。
以上就是复述,持久化之aof方式的详细内容,更多请关注其它相关文章!
