redis持久化 两种方法，4个总结 和 备份恢复

--6.1.Redis 持久化

redis 支持 RDB 和 AOF 两种持久化机制，持久化可以避免因进程退出而造成数据丢失

 

一、RDB 持久化

RDB 持久化把当前进程数据生成快照（.rdb）文件保存到硬盘的过程，有手动触发和自动触发

 

手动触发有 save 和 bgsave 两命令

save 命令：

阻塞当前 Redis，直到 RDB 持久化过程完成为止，若内存实例比较大会造成长时间阻塞， 线上环境不建议用它

bgsave 命令：

redis 进程执行 fork 操作创建子线程，由子线程完成持久化，阻塞时间很短（微秒级）， 是 save 的优化,在执行 redis-cli shutdown 关闭 redis 服务时，如果没有开启 AOF 持久化， 自动执行 bgsave; 显然 bgsave 是对 save 的优化。

 

 

 

RDB 文件的操作

命令：

config set dir /usr/local          //设置 rdb 文件保存路径

备份：

bgsave             //将 dump.rdb 保存到 usr/local 下

恢复：

将 dump.rdb 放到 redis 安装目录与 redis.conf 同级目录，重启 redis 即可

 

 

优点：

1，压缩后的二进制文文件适用于备份、全量复制，用于灾难恢复

2，加载 RDB 恢复数据远快于 AOF 方式

缺点：

1，无法做到实时持久化，每次都要创建子进程，频繁操作成本过高

2，保存后的二进制文件，存在老版本不兼容新版本 rdb 文件的问题

 

 

RDB 配置详解（redis）：

# Save the DB on disk:

save 900 1

save 300 10

save 60 10000

# 设置 sedis 进行数据库镜像的频率。

# 900 秒（15 分钟）内至少 1 个 key 值改变（则进行数据库保存--持久化）。

# 300 秒（5 分钟）内至少 10 个 key 值改变（则进行数据库保存--持久化）。

# 60 秒（1 分钟）内至少 10000 个 key 值改变（则进行数据库保存--持久化）。

 

# 后台存储错误停止写。

stop-writes-on-bgsave-error yes

 

# 在进行镜像备份时,是否进行压缩。yes：压缩，但是需要一些 cpu 的消耗。no：不压缩，需 要更多的磁盘空间。

rdbcompression yes

 

#一个 CRC64 的校验就被放在了文件末尾，当存储或者加载 rbd 文件的时候会有一个 10%左右的 性能下降， 为了达到性能的最大化，你可以关掉这个配置项。

rdbchecksum yes

 

# 快照的文件名

dbfilename dump.rdb

 

# 存放快照的目录

dir /var/lib/redis

 

上面提出了 RDB 持久化的不足，要是不允许数据丢失，则需要用 AOF 来持久化

 

 

如果不做持久化：

#不做持久化，用 replication 去保证可用性，另外最后可以通过应用从数据库同步最新数据， 因此注释掉所有持久化策略，

添加一条带空字符串参数的 save 指令也能移除之前所有配置的 save 指令，

save ""

 

 

测试持久化 RDB：

看后台日志 redis.log

 

关闭持久化

save ""

#save 900 1

#save 300 10

#save 60 10000

 

关闭了也可以用bgsave来持久化数据

 

 

开启持久化：

#save ""

save 900 1

save 300 10

save 60 10000

 

 

总结 1：

开启 RDB 持久化，在满足 save 条件、手动 save、正常关闭的时候数据都会被持久化， 而异常关闭终止的时候数据会丢失。

 

 

2、redis.conf 基本配置: 关闭 snapshot，关闭 rdb

#save 900 1

#save 300 10

#save 60 10000

 

 

总结 2：

关闭持久化，只有在手动 save 的时候数据都会被持久化，正常关闭的时候数据丢失。

要是从一开始到关闭写入数据的期间没有手动 save，则数据全部丢失！

 

 

 

 

二、AOF 持久化

针对 RDB 不适合实时持久化，redis 提供了 AOF 持久化方式来解决

开启：redis.conf 设置：

appendonly yes (默认不开启，为 no)

默认文件名：appendfilename "appendonly.aof"

流程说明：

1，所有的写入命令(set hset)会 append 追加到 aof_buf 缓冲区中

2，AOF 缓冲区向硬盘做 sync 同步

3，随着 AOF 文件越来越大，需定期对 AOF 文件 rewrite 重写，进行压缩

4，当 redis 服务重启，可 load 加载 AOF 文件进行恢复

 

AOF 持久化流程：

命令写入(append),文件同步(sync),文件重写(rewrite),重启加载(load)

 

AOF 配置详解：

appendonly yes       //启用 aof 持久化方式

# appendfsync always //每收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久 化，不推荐使用

appendfsync everysec //每秒强制写入磁盘一次，性能和持久化方面做了折中，推荐

# appendfsync no    //完全依赖 os，性能最好,持久化没保证（操作系统自身的同步）

no-appendfsync-on-rewrite yes //正在导出 rdb 快照的过程中,要不要停止同步 aof

auto-aof-rewrite-percentage 100 //aof 文件大小比起上次重写时的大小,增长率 100%时,重写

auto-aof-rewrite-min-size 64mb //aof 文件,至少超过 64M 时,重写

 

 

 

如何从 AOF 恢复？

1. 设置 appendonly yes；

2. 将 appendonly.aof 放到 dir 参数指定的目录；

3. 启动 Redis，Redis 会自动加载 appendonly.aof 文件。

 

 

redis 重启时恢复加载 AOF 与 RDB 顺序及流程：

1，当 AOF 和 RDB 文件同时存在时，优先加载 AOF

2，若关闭了 AOF，加载 RDB 文件

3，加载 AOF/RDB 成功，redis 重启成功

4，AOF/RDB 存在错误，redis 启动失败并打印错误信息

 

 

总结 3：

redis 重启载入数据的时候，读取 aof 的文件要先于 rdb 文件，所以尽量一开始开启 aof 选项， 不要在中途开启。

 

 

 

测试：

redis.conf 基本配置: 开启 snapshot，开启 aof

save 900 1

save 300 10

save 60 10000

appendonly yes

appendfilename redis.aof

# appendfsync always

appendfsync everysec

# appendfsync no

no-appendfsync-on-rewrite no

auto-aof-rewrite-min-size 64mb

 

 

 

 

#aof,rdb 2 个文件已经生成，并且 aof 文件大小根据操作命令实时增加， 而 rbd 需要手动 save 或者到了刷写机制的阀值才增加

 

flushall

#清除所有数据

 

总结4：持久化改 aof之前，切记要bgrewriteaof

如果是redis运行后，在开启 aof 之前，需要执行命令： bgrewriteaof  执行合并重写功能，生成 AOF 文件，看日志，

否则手工改参数开启 AOF 后，重启 redis，原来的 rdb 会丢失。

 

 

1. 关于 Redis 数据的备份与恢复

备份很简单，只需要把 RDB，AOF 的文件复制备份起来就可以了。相同版本的备份文件可以任意使用，

不同版本没有试过。

 

备份文件

停止

拷回来恢复