Redis7持久化

一、redis持久化

1、RDB

RDB持久性以指定的时间间隔执行数据集的时间点快照
也就是说在一定的时间间隔内，将某一时刻的数据和状态以文件的形式写到磁盘上，这个快照文件交dump.rdb

Redis6更新策略

Redis7更新策略

RDB手动触发

5秒2次修改

RDB手动触发

save:优先级高，执行该命令时其他进程都会停下来等这个命令执行完，因此在此期间redis对外缓存功能失效，很少用
bgsave:在执行该命令的时候，redis产生一个fork，相当于复制了一个父进程，由此来异步保存RDB

lastsave   //查看上一次保存的时间戳，在linux下查看日期

优缺点

RDB修复命令

哪些操作会触发RDB快照

• 配置文件中默认的快照配置
• 手动 save/bgsave 命令
• 执行flush / flushdb 命令也会产生 dump.rdb 文件，但里面是空的，无意义
• 执行 shutdown 且没有设置开启 AOF 持久化
• 主从复制时，主节点自动触发

如何禁用快照
动态所有停止 RDB 保存规则的方法: redis-cli config set save “”
快照禁用

RDB优化参数

小结

2、AOF

只记录写操作

AOF 持久化工作流程

AOF 缓冲区三种写回策略

• always 同步写回，每个写命令执行完立刻同步地将日志写回磁盘
• everysec (默认)每秒写回，每个写命令执行完，只是先把日志写到AOF缓冲区，每隔1s把缓存区地数据写入磁盘
• no操作系统控制写回，只是将日志先写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

AOF功能配置

AOF正常恢复

AOF正常恢复是写在incr文件

AOF异常恢复

比如，模拟incr文件错误

结果：当AOF文件破损后，redis启动都1启动不了

AOF文件异常修复

//命令：
redis-check-aof --fix appendonly.aof.1.incr.aof

AOF的优缺点

AOF重写机制

自动配置

• 满足配置文件中的选项后，Redis会记录上次重写时地AOF大小
• 默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时
  
  
  手动配置
• 客户端向服务器发送 bgrewriteaof 命令
  

小结

3、RDB+AOF混合

AOF默认是关闭的，当两者共存时，AOF的优先级高

同时开启两种持久化方式

• 当redis 重启时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
• RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。
  • 那要不要只使用AOF呢
    • 安特雷兹建议不要
    • 因为RDB更适合用于备份数据库（AOF不断变化不好备份），留着AOF作为一个万一的手段
      

4、纯缓存模式

同时关闭RDB + AOF

• save “”
  • 禁用rdb
  • 禁用db持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件
• appendonly no
  • 禁用aof
  • 禁用aof持久化模式下，我们仍然可以使用命令 bgrewriteaof生成aof文件