©2020-2024 ioDraw All rights reserved,
Privacy Policy
<>一、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文件