Table of Contents

Redis presistence

docker-redis

步骤

copy redis.conf 并修改,创建预设的数据卷

pull images&&run container

docker run -d \
-v /storage/predis/conf/redis.conf:/usr/local/etc/redis/redis.conf \
-v /storage/predis/dump:/data \
--name  predis redis \
redis-server /usr/local/etc/redis/redis.conf

配置文件(redis.conf)

command	description
dbfilename	filename where dump the DB
save	设置快照时间，默认关闭
dir	工作路径
stop-writes-on-bgsave-error yes	当快照写入出错时，Redis 是否接受新的写请求
rdbcompression yes	设置是否压缩存储 (LZF 算法)，会消耗 CPU 资源
rdbchecksum yes	储存 snapshot 后进行 CRC64 校验，产生约 10% 性能损耗
rdb-del-sync-files no	是否删除主从复制禁用 RDB 功能的 RDB 文件
protected-mode yes	默认启动，限制外部连接
daemonize no	是否开启守护线程，docker 部署不需要，docker run -d 本身就是后台启动，否则冲突
appendonly no	是否 AOF 持久化，默认关闭
appenddirname	AOF 文件夹名
appendfilename	AOF 文件名的前缀，Redis 7 修改为 MP-AOF
auto-aof-rewrite-percentage	自动重写比例
auto-aof-rewrite-min-size	自动重写文件最大体积

RDB(redis database)

概念

固定频率将某一时刻的数据和状态以文件的形式写入到磁盘,RDB文件(dump.rdb),执行全量快照

操作

自动备份

执行flushall /flushdb命令会产生dump.db文件,内容为空

redis重启时,从配置dumpFile目录读取文件,恢复数据

备份文件dump.rdb和生产redis服务器尽量不置于同一台机器

手动备份

save 主程序阻塞redis进程,直到持久化工作完成,线上禁止使用

bgsave(default) redis在后台异步进行快照操作,不阻塞快照同时可以响应客户端请求,此触发方式会fork一个子进程复制持久化过程

lastsave 获取最后一次成功执行快照的时间date -d @时间戳

触发RDB snapshot 条件

配置文件的默认快照

save/bgsave

flushall /flushdb

执行shutdown 并未设置开启AOF持久化

主从复制,主节点自动触发

缺点

可能在故障(down)时丢失最新数据(快照之间的数据)

内存数据的全量同步,数据量较大时影响服务器性能

主进程fork后,可能会导致服务请求的瞬间延迟

dump.rdb可能损坏,修复命令 redis-check-rdb /../dump.rdb

禁用snapshot 修改配置文件 save ""

总结

适合大规模数据恢复

按照业务定时备份

对数据完整性和一致性要求不高

rdb文件在内存的加载速度比aof更快

AOF(append only file)

工作流程

Client 作为命令的来源,会有多个源头以及源源不断的请求命令

命令到达redis server 后,存入aof缓存区,等待达到一定量时写入磁盘

Aof缓冲会根据Aof缓冲区同步文件的三种写回策略写入磁盘的aof文件

为Aof内容的增加避免文件膨胀,根据规则进行命令合并(AOF重写),达到压缩效果

写回策略

Always 同步写回,每个写命令执行完会立刻同步的将日志写回磁盘

everysec 每秒写回,每个写命令执行完,存入Buffer,每隔一秒将Buffer内容写入Disk

no OS控制写回,每个写命令执行完,先将日志写入到AOF文件的缓冲区,由OS决定何时将Buffer写回Disk

MP-AOF

mp-aof将原来的单个aof文件拆分为多个aof文件(redis7),三种类型

BASE : 基础AOF,一般由子进程通过重写产生,此文件数量最大为1

INCR:增量AOF,一般会在AOFRW开始时创建,文件可能多个(一般W操作影响此文件)

HISTORY:历史AOF,由BASE和INCR AOF变化而来,每次AOFRW成功完成时,本次AOFRW之前对应的BASE和INCR都会变为HISTORY,此类型会被redis自动删除

为管理aof文件,引入manifest文件,所用aof的相关文件会在appenddirname中

缺点

相同数据集一般aof大于rdb,恢复速度aof慢于rdb

aof运行效率一般低于rdb

恢复redis-check-aof --fix ...

重写机制

问题:由于AOF持久化是将Redis不断写命令记录到AOF文件中,随着Redis运行,aof文件体积膨胀,占用服务器内存加剧且恢复时间加长,触发重写,保留恢复数据的最小指令集

触发机制

自动触发:满足配置文件(auto-aof-rewrite-precentage,auto-aof-rewrite-min-size)的选项,redis自动记录上次重写的AOF文件大小
    达到条件时,重写base aof文件,pid增加,incr文件清零

手动触发:client发送bgrewrite指令

总结

数据实时保存,记录完整的读写命令,同步性更高

aof日志文件更加灵活,便于追日志

混合模式

设置aof-use-rdb-preamble yes,前提开启aof

RDB镜像做全量持久化,AOF做增量持久化,先使用rdb进行快照存储,然后使用AOF持久化所有写操作,当重写策略满足或者手动触发重写时,将最新的数据存储为RDB记录,重启服务会从二者中恢复数据

纯缓存模式

同时关闭AOF和RDB ,设置redis.conf save " " appendonly no,保证性能