redis学习3---持久化

1、默认持久化

表示在900s存一个对象，300s存10个对象，60s存10000个对象时就会自动触发RDB的持久化

save 900 1

save 300 10

save 60 10000

快照文件名，可自定义

dbfilename dump.rdb

快照文件保存目录

dir ./

如果bgsave出现错误,是否停止写入，一般都配置为yes

stop-writes-on-bgsave-error yes

开启压缩rdb

rdbcompression yes 

检验和

rdbchecksum yes

如果想要关闭快照持久化，做下面修改：

注释快照持久化规则

#save 900 1

#save 300 10

#save 60 10000

设置为空

save ""

之后重启redis

备份 save 说明：

可以使用 SAVE 和 BGSAVE 命令手动备份，两者有区别 ： SAVE命令表示使用主进程将当前数据库快照到dump文件 ， BGSAVE命令表示，主进程会fork一个子进程来进行快照备份。前者会阻塞主进程，而后者不会，所以一般使用BGSAVE进行手动备份。

可以使用命令关闭db，不需要重启服务

config set save ""

查看是否生效

config get save

2、如果想使用aof方式做持久化

开启appendonlylog，开启的话每次写操作会记一条log。相当于mysql的binlog；不同的是，每次redis启动都会读此文件构建完整数据。即使删除rdb文件，数据也是安全的

appendonly no

>>

appendonly yes 

aof文件保存目录和文件名可以自定义

dir ./

appendfilename "appendonly.aof"

aof策略，每秒钟强制写入磁盘一次

appendfsync everysec

在重写时是否不需要append,这个配置需要根据实际权衡，因为在重写的同时进行append会有性能开销，当然如果不append也可能会丢失少量数据，以性能为优先的时候关闭append

no-appendfsync-on-rewrite no

>>

no-appendfsync-on-rewrite yes

使用命令关闭aof

config set appendfsync no 

查看是否生效

config get appendfsync

3、RDB和AOF方式持久化比较

RDB触发机制：

save(同步)

执行一条save命令,就会生成一个RDB文件

阻塞（保存是阻塞主进程，客户端无法连接redis，等SAVE完成后，主进程才开始工作，客户端可以连接）

bgsave(异步)

执行bgsave命令

fork()一个子进程在后台去创建RDB文件

不影响主进程，客户端可以正常链接redis，等子进程fork执行save完成后，通知主进程，子进程关闭。

RDB持久化是指在指定的时间间隔内将内存中的数据和操作通过快照的方式保存到dump.rdb文件，RDB 是一个非常紧凑（compact）的文件，本身文件比较小， 这种文件非常适合用于进行备份。恢复直接载入到内存即可，所以恢复数据比较快。但是如果服务器在非备份时间跨度内发生了故障，无法做到对当前状态的实时保存，导致数据丢失，另外遇到宕机等情况的时候快照的数据可能会不完整。每次保存 RDB文件时，save会阻塞Redis， bgsave不会阻塞Redis，但是需要 fork()出一个子进程，由子进程来执行具体的持久化工作，在数据集比较庞大时，fork()可能会非常耗时，造成服务器在某某毫秒内停止处理客户端，对CPU资源消耗较大，甚至可能使得这种停止时间长达整整一秒。

AOF持久化是在每次接受到的写命令通过 write函数追加到appendonly.aof文件，使用策略可以最大限度的保证意外情况下的数据完整性，每秒钟一次 fsync ，或者每次执行写入命令时 fsync。AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据，（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。因为 AOF 的运作方式是不断地将命令追加到文件的末尾，恢复数据就是逐条的执行命令，所以随着写入命令的不断增加， AOF 文件的体积也会变得越来越大，也会使得恢复过程变得漫长。

两种方式恢复数据：

RDB：

制定策略，自动定时的把dump.rdb文件备份到备机上，恢复过程就是把备机的文件拷贝到redis服务器快照文件存放目录下，命名为dump.rdb，然后启动redis服务即可。

AOF：

假如当不小心执行了 flushall 清除了所有的数据后，打开 appendonly.aof 的文件，删除末尾的命令 flushall ，最好利用 redis-check-aof这个工具来检测一下你修改过后的 aof 文件是否正常，以防启动恢复数据的时候出错，显示 AOF is valid aof 说明文件是有效的，那么可以重启 redis 恢复数据了。

两种方式选择：

只做缓存，如果希望数据在服务器运行的时候存在，可以不使用任何持久化。

如果可以忍受一段时间的数据丢失可以使用RDB方式

如果要求数据实时备份，就需要选择AOF方式

建议同时开启两种持久化：

在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据

不建议只使用AOF，因为AOF持久化存在潜在的BUG

RDB文件用作后备用途，建议只保留 save 900 1 这条规则

应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

4、解决redis aof文件过大的问题

执行BGREWRITEAOF命令对redis的AOF进行重写

redis-cli BGREWRITEAOF

AOF重写：

(1) 随着AOF文件越来越大，里面会有大部分是重复命令或者可以合并的命令（100次incr = set key 100）

(2) 重写的好处：减少AOF日志尺寸，减少内存占用，加快数据库恢复时间。

执行一个 AOF文件重写操作，重写会创建一个当前 AOF 文件的体积优化版本。

即使 BGREWRITEAOF 执行失败，也不会有任何数据丢失，因为旧的 AOF 文件在 BGREWRITEAOF 成功之前不会被修改。

默认自动触发重写规则

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

percentage是指，当redis当前的aof文件大小相对于上一次进行rewriteaof操作时的大小增长率大于100%时，就会进行rewrite。

但是，当增长率大于了100%，实际上aof文件其实很小，这样rewrite就没有必要了，所以，还需要设置一个min-size，当redis的增长率大于100%，并且min-size的大于64mb时，就会执行rewriteaof操作。

5、RDB和AOF其他

5.1、重写

如果想关闭rewriteaof操作，可以将percentage设置为0。

redis会在以下三个时候进行rewrite操作

Redis接收到客户端发送的bgrewriteaof命令

Redis aof文件增长率和增长大小达到auto-aof-rewrite

Redis接收到客户端发送的”CONFIG SET appendonly yes”命令

5.2、 数据恢复顺序

当redis重启时，会按照以下优先级进行启动：

如果只配置AOF,重启时加载AOF文件恢复数据；

如果同时 配置了RBD和AOF,启动是只加载AOF文件恢复数据;

如果只配置RBD,启动时将加载dump文件恢复数据。

5.3、AOF配置文件损坏修复方法

对于错误格式的AOF文件，先进行备份，然后采用redis-check-aof--fix命令进行修复，修复后使用diff-u对比数据的差异，找出丢失的数据，有些可以人工修改补全。AOF文件可能存在结尾不完整的情况，比如机器突然掉电导致AOF尾部文件命令写入不全。Redis为我们提供了aof-load-truncated配置来兼容这种情况，默认开启。加载AOF时，当遇到此问题时会忽略并继续启动。