Redis持久化和备份数据

一、持久化

实现持久化的方式有两种RDB、AOF

基于RDB方式做持久化

RDB是基于快照模式实现的，所保存的数据文件默认dump.rdb，具体产生这个数据文件的方式有两种：
方式1：客户端执行save或者bgsave命令

用save方式你的话，是在主线程中保存快照，也就是说在save执行完成之前所有的操作都会被阻塞，因为这是同步保存的。
在执行save保存数据的时候，不是做增量保存，而是将内存中的全部数据做一次同步，所以这个过程会很慢。
用bgsave的话，这个是基于异步的方式，也就是执行这个命令以后，会立刻告诉你已经执行启动，但是不会阻塞用户，而是在后台悄悄的运行。

方式2：提前做好计划任务

基于计划任务自动做同步的话，是在子进程中实现。具体过程是子进程会会打开一个文件，将数据保存到这个新文件中，在完成以后改名为dump.rdb就可以了。

基于AOF方式做持久化

相对而言，AOF模式比RDB更为可靠。这种方式之所以可靠是因为快照的方式是周期性的，比如每隔10秒做一次，但是如果在做了一次持久化之后，还没有到下一次系统就崩溃了，那么这段时间的数据就丢失了。
AOF有有点类似于mysql的二进制日志，这个文件会记录下每次所执行的语句（主要是写操作），每次的操作都会追加到文件的末尾。当Redis重启的时候，可以通过aof文件中的命令实现在内存中重建数据库。

但是aof这种方式也是有缺点的：

可能会有很多重复的内容，比如执行100次incre，文件就会记录100条，这明显是不合理的（事实上redis进程会扫描aof中重复的事件，并进行合并）
aof文件会变得越来越大，为了解决这个问题，redis提供了一个命令BGREWRITEAOF，通过这个命令可以实现AOF文件的重写，需要注意的是这种重写机制是比较特殊的，因为在重写的时候，是不会去读取原来的aof文件，而是直接读取内存中的数据，将内存中的数据生成一个指令集，并将指令集保存在一个临时文件，在这个临时文件保存完成之后，就会用这个历史文件去替换原来的那个aof文件，完成重写aof文件的过程。so，aof文件可以通过重写的方式将其变小。

重写过程：

Redis主进程通过fork创建子进程；
子进程根据Redis内存中的数据创建数据库重建命令序列于临时文件中；
父进程继承 client的请求，并会把这些请求中的写操作继续追加到原来的aof文件，额外地，这些新的写请求还会被防止于一个新的缓冲队列中；
子进程重写完成，会通知父进程，父进程把缓冲中的命令写到临时文件中
父进程用临时文件替代aof文件；

相关配置

与RDB相关的配置

# 设置同步周期
save 900 1
save 300 10
save 60 10000
# 进行快照备份的时候，一旦监控到持久化发生了错误，是否停止下来
stop-writes-on-bgsave-error yes
# rdb文件是否执行压缩来节省空间
rdbcompression yes
# 是否校验rdb文件
rdbchecksum yes
# rdb文件的文件名
dbfilename dump.rdb
# rdb文件的位置
dir /var/lib/redis

与AOF相关的配置

# 指定是否启用aof持久化
appendonly yes        
# 当aof文件的大小增长了指定比例的时候，执行一次重写操作        
auto-aof-rewrite-percentage 100  
# 指定aof文件做重写最小值
auto-aof-rewrite-min-size 64mb   
# aof持久化信息保存在哪个文件中（相当于mysql的二进制日志文件）
appendfilename "appendonly.aof" 
# 一旦执行了操作，会立刻将操作的语句记录到aof文件中
# appendfsync always
# 每秒向aof文件进行一次写入操作            
appendfsync everysec 
# 不主动向aof执行写入操作，由系统自行判断何时向磁盘执行写入操作            
# appendfsync no 
#在做重写的时候，新的写操作不做fsync                
no-appendfsync-on-rewrite no
# 当aof文件备被损坏时，redis返回错误并推出
aof-load-truncated yes

实际生产环境中肯定是同时使用rdb和aof的，那么就会有一个问题，就是如果在某个时间点同时出发了AOF和RDB持久化，那么会对磁盘熊带来很大的压力，所以通常我们的Redis会禁止同时做持久化操作，如果正在做RDB的持久化，那么及时此时触发了AOF的持久化也是不会执行的。

二、备份

在有持久化的情况下，数据会自动保存在文件中，这里为了演示现将持久化关闭。

# 修改配置文件
[root@BIGBOSS ~]# vim /etc/redis.conf 
# 禁止快照方式的持久存储
save ""

#save 900 1
#save 300 10
#save 60 10000
# 禁止AOF方式的持久存储
appendonly no

删除之前的数据,并重启服务

[root@BIGBOSS ~]# rm -rf /var/lib/redis/dump.rdb 
[root@BIGBOSS ~]# systemctl restart redis

在redis中填充一些数据

10.220.5.171:6379> DBSIZE
(integer) 0
10.220.5.171:6379> set name cx
OK
10.220.5.171:6379> set age 20
OK
10.220.5.171:6379> set addr tianjin
OK
10.220.5.171:6379> DBSIZE
(integer) 3

退出redis，再重新进入发现这些key依然存在（这些值是存在内存中的）

10.220.5.171:6379> exit
[root@BIGBOSS ~]# redis-cli -h 10.220.5.171
10.220.5.171:6379> DBSIZE
(integer) 3

但是如果重启Redis这些数据就没有了

10.220.5.171:6379> exit
[root@BIGBOSS ~]# systemctl restart redis
[root@BIGBOSS ~]# redis-cli -h 10.220.5.171
10.220.5.171:6379> DBSIZE
(integer) 0

重新插入数据,并手动执行保存

10.220.5.171:6379> DBSIZE
(integer) 0
10.220.5.171:6379> set name cx
OK
10.220.5.171:6379> set age 20
OK
10.220.5.171:6379> set addr tianjin
OK
10.220.5.171:6379> save
OK

可以看到生成了新的数据文件

[root@BIGBOSS ~]# ls /var/lib/redis/
dump.rdb

而我们做备份工作的时候，其实就是备份的这个文件，现在我将这个文件备份到tmp下

[root@BIGBOSS ~]# cp /var/lib/redis/dump.rdb  /tmp/

模拟故障，将/var/lib/redis/dump.rdb删除并重启redis,可以看到数据已经没有了，不过不要慌我们做了备份

[root@BIGBOSS ~]# rm -rf /var/lib/redis/dump.rdb
[root@BIGBOSS ~]# systemctl restart redis
[root@BIGBOSS ~]# redis-cli -h 10.220.5.171
10.220.5.171:6379> DBSIZE
(integer) 0

将备份数据挪回来，重启Redis查看数据

[root@BIGBOSS ~]# cp /tmp/dump.rdb  /var/lib/redis/
[root@BIGBOSS ~]# ls /var/lib/redis/
dump.rdb
[root@BIGBOSS ~]# systemctl restart redis
[root@BIGBOSS ~]# redis-cli -h 10.220.5.171
10.220.5.171:6379> DBSIZE
(integer) 3

通过上面的操作很明显的我们看到了备份数据和恢复数据的过程，在企业中数据备份也是很重要的一份工作。

------做运维之前很矫情的小年轻-----