如果同时有RDB与AOF文件,则恢复数据时优化AOF,因为AOF数据会比较全
RDB:根据配置的间隔生成快照
相关配置:
【RDB 方式保存配置】
# rdb 方式保存进行压缩
rdbcompression yes
#
rdbchecksum yes
# rdb 文件名
dbfilename dump.rdb
优点:
数据文件紧凑;fork子进程进行数据处理;恢复大数据集的时候比AOF快
缺点:
在大数据集中,需要保存整个数据集的状态,操作保存动作时间久
AOF:以Redis的协议格式追加的形式记录写操作命令;使用 rewrite 优化aof文件;
相关配置:
# 【AOF 配置】
# 是否开启,如果里面已经有数据了,则在开启这个之后,重启Redis会清空所有数据
appendonly no
# AOF文件
appendfilename "appendonly.aof"
# AOF记录规则,【一直同步|每秒同步|不自动,交给操作系统】
appendfsync everysec
# AOF是否重写,如果开启了,则会减小文件体积,相同的命令不会多次记录,即:对一个key,只有一条记录操作
no-appendfsync-on-rewrite no
# AOF文件重写规则
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
优点:
同步间隔秒级;只能文件追加,速度快;自动重写【优化】AOF文件;有恢复当前数据集的所有最小化命令,数据完整性好
缺点:可能会未知的BUG;数据集大时,载入AOF文件慢;
执行步骤:
1. fork子进程;
2. 子进程将新的AOF内容写到临时文件
3. 父进程对所有新AOF内容缓存到内存,且保存到原AOF文件,保证数据不会丢失
4. 子进程完成后,给父进程一个信号,开始写入父进程缓存的写入命令
5. 替换原来的AOF文件
持久化的一些命令:
bgrewriteaof # 后台重写aof文件
bgsave # 后台生成快照
save # 马上生成快照
redis-check-aof # aof 文件有异常时,此命令会修复,例如:执行的命令只写入了一半,导致不命令不完整【软件包中的相关程序,不是redis里面的命令】
RDB 与AOF的切换:
1. 备份 dump.rdb 文件
2. config set appendonly yes # 开启AOF
3. config set save "" # 【可选】关闭RDB
4. config rewrite # 保存变更的配置到redis.conf