Redis之持久化RDB&AOF

RDB
AOF

• RDB(Redis DataBase),默认开启,RDB方式是通过快照(snapshotting)完成的.所以redis不保证数据的完整性.
  • 触发快照的方式
    • 符合自定义配置的快照规则
    • 执行save或bgsave命令
    • 执行flushall命令(执行前快照一次)
    • 执行主从复制操作(第一次)
  • 基于自定义配置的快照规则
  • 打开redis.conf 搜索 SNAPSHOTTING,可以看到相关配置
    
    可以取消注释,开启快照
    默认是
    3600秒内有1次key的变更;300秒内有100次key的变更;60秒内有10000次的key的变更均会进行快照存储数据.
  • 当硬盘满了,是否关闭redis的写操作,默认是yes

    stop-writes-on-bgsave-error yes
    

  • 是否进行数据压缩后存储,默认yes

    rdbcompression yes
    

  • 是否进行完整性检查,默认yes -> 使用CRC64算法进行校验

    rdbchecksum yes
    

  • 持久化文件的文件名

    dbfilename dump.rdb
    

  • rdb文件存储位置,默认根目录

    dir ./
    

  • RDB存储过程:
    
    劣势:
    fork的实收,内存中的数据会被克隆一份,大约需要2倍的空间
    RDB持久化可能会造成数据的不完整,如:采用每300秒备份一次的策略,如果在第290秒宕机,会丢失这290秒内的数据

---

• AOF(Append Only File),AOF是以日志的形式来记录每个写操作的(增量保存),并会将redis所有执行过的写指令记录下来(读操作不记录),只允许追加文件不可以修改文件.

  • 默认关闭

    appendonly no
    

  • 文件默认名称

    appendfilename "appendonly.aof"
    

  • 默认存储位置: 根目录(和RDB相同)

    dir ./
    

  • 如果遇到aof文件损坏,可以通过 /use/local/bin/redis-check-aof 进行恢复,重启redis进行重新加载,命令:

    redis-check-aof --fix appendonly.aof
    

  • AOF同步频率

    # 每次Redis的写入都会立刻记录到日志;性能较差,单数据完整性较好
    # appendfsync always
    # 默认配置 , 每秒写入日志一次,如果宕机,本秒的数据可能丢失
    appendfsync everysec
    # redis不主动同步,把同步时机交给操作系统
    # appendfsync no
    

  • 日志压缩重写,默认no

    no-appendfsync-on-rewrite no
    

    如

    # 压缩前
    set k1 v1
    set k2 v2
    # 压缩后
    set k1 v1 k2 v2
    

    当当前aof文件达到64M并且是上一次重写后的体量增加100%时会自动触发重写

    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb
    

  • AOF存储过程
    

  • 优势:
    相比RDB数据完整性可能更好一些,数据丢失概率更低
    可读的日志文件,可以处理误操作

  • 劣势:
    因为还要存储写操作的命令,需要更多的存储空间
    恢复速度慢
    每次都同步的话,有一定性能压力

---

其他章节 -> 跳转

end...