Redis_持久化

  • AOF(Append Only File)
    –是什么？
    以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只允许加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
    – 默认是关(需要手动打开)
    – 默认文件名字

    –追加策略

    Always:同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好
    Everysec:出厂默认推荐，异步操作，每秒记录，如果一秒内宕机，有数据丢失。（默认）
    No
    –
    重写时是否可以运行Appendfsync,用默认no即可，保证数据安全性。

–重写的触发条件

Auto-aof-rewrite-min-size:设置重写的基准值
Auto-aof-rewrite-percentage:设置重写的基准值

  • AOF启动/修复/恢复
    – 正常恢复
    1.启动：设置Yes：修改默认的appendonly no，改为yes
    2.将有数据的aof文件复制一份保存到对应目录(config get dir)
    3.恢复：重启redis然后重新加载
    – 异常恢复
    1.启动：设置Yes：修改默认的appendonly no，改为yes
    2.备份被写坏的AOF文件
    3.修复：Redis-check-aof --fix 进行修复
    4.恢复：重启redis然后重新加载

  • Rewrite
    – 是什么？
    AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof.
    – 重写原理：
    AOF文件持续增长而过大时，会fork出一条新的进程来将文件重写（也是先写临时文件最后在rewrite），遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
    – 触发机制
    Redis会记录上次重写时的AOF大小，默认配置是AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

  • 优势
    –每秒同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
    – 每修改同步：appendfsync everysec 异步操作 ，每秒记录，如果一秒内宕机，有数据丢失
    –不同步：appendfsync no 从不同步

  • 缺点
    –相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
    –AOF运行效率要慢于rdb，每秒同步策略效率 较好，不同步效率和rdb相同

  • 总结
    –

    – 同时开启两种持久化方式
    1.在这种情况下，当Redis重启的时候优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要毕RDB文件保存的数据集要完整。
    2.RDB的数据不实时，同时使用两者服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。