Redis数据持久化

Redis所有数据都是保存在内存中。 Redis数据备份可以定期地通过异步方式保存到磁盘上，该方式称为半持久化模式，如果每一次数据变化都写人AOF文件里面，则称为全持久化模式。同时还可以基于 Redis主从复制实现 Redis备份与恢复

一、半持久化RDB模式（redis database）

1.自动触发持久化

半持久化RDB模式也是 Redis备份默认方式，是通过快照( snapshotting)完成的，当满足在 redis.conf配置文件中设置的条件时， Redis会自动将内存中的所有数据进行快照并存储在硬盘上，完成数据备份Redis进行RDB快照的条件由用户在配置文件中自定义，由两个参数构成：时间和改动的键的个数。当在指定的时间内被更改的键的个数大于指定的数值时就会进行快照。在配置文件中已经预置了以下3个条件

1）save 900 1:900s内有至少1个键被更改则进行快照。
2）save 300 10:300s内有至少10个键被更改则进行快照。
3）save 60 10000:60s内有至少10000个键被更改则进行快照

#关闭Redis服务自动快照备份
save ""

#yes时因空间满等原因快照无法保存出错时，禁止redis写入操作，建议为no
stop-writes-on-bgsave-error yes
#持久化到RDB文件时，是否压缩，"yes"为压缩，"no"则反之
rdbcompression yes 
#是否对备份文件开启RC64校验，默认是开启
rdbchecksum yes 
#快照文件名
dbfilename dump.rdb 
#快照文件保存路径，示例：dir "/app/redis/data"
dir /app/redis/data

默认可以存在多个条件，条件之间是或的关系，只要满足其中一个条件，就会进行快照。

如果想禁用自动快照，只需要将所有的save参数删除即可。 Redis默认会将快照文件存储在 Redis数据目录，默认文件名为dump.rdb文件，可以通过配置dir和 filename两个参数分别指定快照文件的存储路径和文件名。也可以在 Redis命令行执行 config get dir获取

1.1设置同步规则

打开redis.conf文件，加入如下配置
save 60 3       ##意思代表60s内有3个键发生变化，则自动持久化

1.2设置key

[root@redis bin]# ./redis-cli -h 127.0.0.1
127.0.0.1:6379> set a 100
OK
127.0.0.1:6379> set b 200
OK
127.0.0.1:6379> set c 300
OK
127.0.0.1:6379> set d 400
OK
127.0.0.1:6379> exit


[root@redis bin]# ll
total 18464
-rw-r--r-- 1 root root     121 Oct 29 20:24 dump.rdb    ##发现数据已经被持久化

1.3测试数据是否被持久化

将redis停止，同时将dump.rdb文件改名，查看数据是否存在

##停止redis
[root@redis bin]# ps -ef |grep redis
root      27578      1  0 20:25 ?        00:00:00 ./redis-server 127.0.0.1:6379
root      27684  23908  0 20:27 pts/1    00:00:00 grep --color=auto redis
[root@redis bin]# kill -9 27578


##将rdb文件别名
[root@redis bin]# mv dump.rdb dump.rdb.bak

##启动redis查看数据是否存在
[root@redis bin]# ./redis-server /usr/local/src/redis-6.0.16/redis.conf
[root@redis bin]# ./redis-cli -h 127.0.0.1
127.0.0.1:6379> keys *
(empty array)                    ##是空的，说明数据没有被持久化

##将redis数据库停止
[root@redis bin]# ps -ef |grep redis
root      28360      1  0 20:40 ?        00:00:00 ./redis-server 127.0.0.1:6379
root      28384  23847  0 20:40 pts/0    00:00:00 grep --color=auto redis
[root@redis bin]# kill -9 28360

##将rdb文件重新修改成dump.rdb，并重启redis
[root@redis bin]# mv dump.rdb.bak dump.rdb
[root@redis bin]# ./redis-server /usr/local/src/redis-6.0.16/redis.conf
[root@redis bin]# ./redis-cli -h 127.0.0.1
127.0.0.1:6379> keys *           ##数据恢复了
1) "b"
2) "d"
3) "a"
4) "c"

2.手动操作持久化

##save持久化---阻塞型
[root@redis bin]# ./redis-cli  -h 127.0.0.1
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set name zhangsan
OK
127.0.0.1:6379> set age 30
OK
127.0.0.1:6379> set add hubei
OK
127.0.0.1:6379> save               ##手动持久化
OK

##查看数据
[root@redis src]# vim dump.rdb
[root@redis src]# cat dump.rdb
REDIS0009	redis-ver6.0.16
redis-bits󿿀򳨭e^
              ]used-memP%
            aof-preamble~񃭡mzhangsanaddhubeiage󿾞ÿÿ皪   ##数据是不可读的，只能看到大概数据
                         
#bgsave手动同步  ----非阻塞型
[root@redis bin]# ./redis-cli -h 127.0.0.1
127.0.0.1:6379> set a 100
OK
127.0.0.1:6379> set b 200
OK
127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379>

注意：
save:该命令会阻塞redis服务器，执行save期间，redis不能再处理其他命令，直到RDB过程完成为止，优点是操作简单

bgsave:该命令不会阻塞redis,会生成一个分支线程来进行持久化，主线程仍然能够接收命令操作，优点是对用户友好。

2.1 模拟save和bgsave数据持久化过程

为了演示，我们一次性在redis数据库中增加1000W条数据

a.save持久化

 2>bgsave持久化

2.2同步后的备份数据

[root@redis bin]# ll
total 279964
-rw-r--r-- 1 root root 267777882 Oct 29 19:45 dump.rdb  ##大小急剧增加

 2.3Redis bgsave实现数据持久化过程

1、Redis父进程首先判断：当前是否在执行save，或bgsave/bgrewriteaof的子进程，如果在执行则bgsave命令直接返回。bgsave/bgrewriteaof（aof） 的子进程不能同时执行，主要是基于性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。
2、父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令
3、父进程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父进程，并可以响应其他命令
4、子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换
5、子进程发送信号给父进程表示完成，父进程更新统计信息

 1.3RDB的备份过程

Redis从master主进程先fork出一个子进程，使用写时复制机制，子进程将内存的数据保存为一个临时文件，比如`temp-<子进程pid>.rdb`，当数据保存完成之后再将上一次保存的RDB文件替换掉，然后关闭子进程，这样可以保存每一次做RDB快照的时候保存的数据都是完整的，因为直接替换RDB文件的时候可能会出现突然断电等问题而导致RDB文件还没有保存完整就突然关机停止保存而导致数据丢失的情况，可以手动将每次生成的RDB文件进程备份，这样可以最大化保存历史数据。

1.4fork概念

 Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据（ 变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

在Linux 程序中，fork（）会产生一个和父进程完全相同的子进程，但子进程在此后多会exec 系统调用，出于效率考虑，Linux才引入了 “写时复制技术“

一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

1.5 RDB的优缺点

1>优点

1、适合大规模的恢复
2、对数据完整和一致性要求不高的场景
3、节省磁盘空间
4、恢复速度快

2>缺点

 1、fork的时候需要复制一份内存中的数据，需要大致2倍内存空间的大小的空间存储临时文件--原有的dump.rdb
2、周期性备份数据，如果redis意外宕掉的话容易出现最后一次快照后的数据
3、fork的时候使用了“写时复制”技术，但是数据量过大的话，也会消耗服务器的性能

1.6  一键脚本备份RDB文件

#!/bin/bash
. /etc/init.d/functions
#rdb文件备份目录
BACKUP=/backup/redis-rdb
#rdb文件目录
DIR=/app/redis/data
#rdb文件basename
FILE=dump_6379

#连接redis信息
HOST=127.0.0.1
PASS=123456
PORT=6379

#执行bgsave,备份Redis快照数据
rediscli=/app/redis/bin/redis-cli

$rediscli -h $HOST -a $PASS -p $PORT --no-auth-warning bgsave
result=`$rediscli -h $HOST -a $PASS -p $PORT --no-auth-warning info Persistence |grep rdb_bgsave_in_progress| sed -rn 's/.*:([0-9]+).*/\1/p'`
while [[ ! $result -eq 0 ]] ; do
	sleep 1
	result=`$rediscli -h $HOST -a $PASS -p $PORT --no-auth-warning info Persistence |grep rdb_bgsave_in_progress| sed -rn 's/.*:([0-9]+).*/\1/p'`
done

DATE=`date +%F_%H-%M-%S`
[ -e $BACKUP ] || { mkdir -p $BACKUP; chown -R redis.redis $BACKUP; }
mv ${DIR}/${FILE}.rdb ${BACKUP}/${FILE}-${DATE}.rdb

action "BACKUP REDIS RDB"

二、全持久化AOF模式（append only file）

如果数据很重要无法承受任何损失，可以考虑使用AOF方式进行持久化，默认 Redis没有开启AOF方式的全持久化模式。在启动时 Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中，备份以日志的形式来记录每个写操作（增量保存），将Redis 执行过的所有写指令记录下来(读操作不记录），只许追加文件但不可以改写文件，redis 启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容特写指令从前到后执行，以完成数据的恢复工作。

Redis允许同时开启AOF和RDB，既保证了数据安全又使得进行备份等操作十分容易此时重新启动 Redis后Reds会使用AOF文件来恢复数据，因为AOF方式的持久化可能丢失的数据更少，可以在 redis.conf中通过 appendonly参数开启 Redis AOF全持久

1.编辑redis的配置文件

#dir目录是存放Redis持久化数据文件目录
dir /app/redis/data

#appendnoly设置为yes开启AOF模式,默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了，但是redis如果中途宕机，会导致可能有几分钟的数据丢失(取决于dumpd数据的间隔时间)，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性，Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。默认不启用此功能
appendonly no

#AOF文件名，是文本文件，存放在dir指令指定的目录中
appendfilename "appendonly.aof"

#aof持久化策略的配置
#no表示redis不自动执行fsync,由操作系统保证数据同步到磁盘,Linux的默认fsync策略是30秒，最多会丢失30s的数据
#always表示每次写入都执行fsync,以保证数据同步到磁盘,但是会生成大量磁盘IO
#everysec表示每秒执行一次fsync,可能会导致丢失这1s数据
appendfsync everysec

#在aof rewrite期间,是否对aof新记录的append暂缓使用文件同步策略,主要考虑磁盘IO开支和请求阻塞时间
no-appendfsync-on-rewrite no 
#同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形,以下参数实现控制
#默认为no,表示"不暂缓",新的aof记录仍然会被立即同步到磁盘，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题
#为yes,相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？Linux的默认fsync策略是30秒，最多会丢失30s的数据,但由于yes性能较好而且会避免出现阻塞因此比较推荐


#从 Redis 2.4 开始， AOF 重写由 Redis 自行触发， BGREWRITEAOF 仅仅用于手动触发重写操作
#当Aof log增长超过上次rewrite整理数据文件大小指定百分比例时，重写AOF文件,设置为0表示不自动重写Aof日志，重写是为了使aof体积保持最小，但是还可以确保保存最完整的数据
auto-aof-rewrite-percentage 100 

#自动触发aof rewrite的最小文件大小
#当AOF文件大小达到64M，自动触发rewrite重写整理;当AOF文件大小超过了64M时，按照 auto-aof-rewrite-percentage 增长百分比触发rewrite
auto-aof-rewrite-min-size 64mb 

#是否加载由于某些原因导致的末尾异常的AOF文件(主进程被kill/断电等)，建议yes
aof-load-truncated yes 

aof-use-rdb-preamble no
#redis4.0新增RDB-AOF混合持久化格式，在开启了这个功能之后，AOF重写产生的文件将同时包含RDB格式的内容和AOF格式的内容，其中RDB格式的内容用于记录已有的数据，而AOF格式的内容则用于记录最近发生了变化的数据，这样Redis就可以同时兼有RDB持久化和AOF持久化的优点（既能够快速地生成重写文件，也能够在出现问题时，快速地载入数据）,默认为no,即不启用此功能

 注意：当Redis数据库中存有一定量数据时后，不建议直接修改Redis配置文件开启AOF模式功能；原因是AOF文件比RDB文件优先级高在启动Redis服务，首先忽略RDB文件，直接加载AOF文件数据，但是开启AOF模式功能之前数据并没有记录到AOF文件，此时AOF文件不存在相当于空，一旦启动Redis服务，Redis数据库中数据会被清空

正确开启AOF模式功能

• 第一步：Redis服务运行，通过config 动态开启AOF功能，把现有数据记录到AOF文件中

• 第二步：修改Redis配置文件，从而保证持久开启AOF功能

#config动态临时开启aof功能
[root@centos7 ~ ]# redis-cli -h 127.0.0.1 -a 123456 --no-auth-warning config set appendonly  yes
OK

[root@centos7 ~ ]# redis-cli -h 127.0.0.1 -a 123456 --no-auth-warning config get appendonly
1) "appendonly"
2) "yes"

#AOF模式开启子进程
[root@centos7 ~ ]# pstree -p
           ├─redis-server(2591)─┬─redis-server(2751)
           │                    ├─{redis-server}(2592)
           │                    ├─{redis-server}(2593)
           │                    └─{redis-server}(2594)

#AOF生成数据文件时也会生成临时文件
[root@centos7 ~ ]# ll  /app/redis/data/
-rw-r--r-- 1 redis redis         0 Sep 13 22:59 appendonly.aof
-rw-r--r-- 1 redis redis 120620934 Sep 13 20:24 dump_6379.rdb
-rw-r--r-- 1 redis redis  50868229 Sep 13 23:06 temp-rewriteaof-2751.aof

#Redis会在配置项dir指定目录下生成appendonly.aof文件，记录当前Redis存放的数据信息
[root@centos7 ~ ]# ll  /app/redis/data/
-rw-r--r-- 1 redis redis 120620934 Sep 13 22:59 appendonly.aof
-rw-r--r-- 1 redis redis 120620934 Sep 13 20:24 dump_6379.rdb

#查看日志
[root@centos7 ~ ]# tail -f /app/redis/log/redis_6379.log
2591:M 13 Sep 2021 23:11:42.722 * Background append only file rewriting started by pid 2823
2591:M 13 Sep 2021 23:11:46.982 * AOF rewrite child asks to stop sending diffs.
2823:C 13 Sep 2021 23:11:46.982 * Parent agreed to stop sending diffs. Finalizing AOF...
2823:C 13 Sep 2021 23:11:46.982 * Concatenating 0.00 MB of AOF diff received from parent.
2823:C 13 Sep 2021 23:11:46.982 * SYNC append only file rewrite performed
2823:C 13 Sep 2021 23:11:46.988 * AOF rewrite: 6 MB of memory used by copy-on-write
2591:M 13 Sep 2021 23:11:47.001 * Background AOF rewrite terminated with success
2591:M 13 Sep 2021 23:11:47.001 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
2591:M 13 Sep 2021 23:11:47.001 * Background AOF rewrite finished successfully

#修改Redis配置文件
[root@centos7 ~ ]# vim /app/redis/etc/redis_6379.conf
appendonly yes

2.如果rdb和aof同时存在，听谁的？

127.0.0.1:6379> keys *       ##查看数据库是空
(empty array)
127.0.0.1:6379> exit
[root@redis bin]# ll
total 18540
-rw-r--r-- 1 root root   79583 Oct 29 20:53 dump.rdb          ##rdb存在数据
-rwxr-xr-x 1 root root  738264 Oct 29 13:46 redis-benchmark
-rwxr-xr-x 1 root root 5697416 Oct 29 13:46 redis-check-aof
-rwxr-xr-x 1 root root 5697416 Oct 29 13:46 redis-check-rdb
-rwxr-xr-x 1 root root 1065840 Oct 29 13:46 redis-cli
lrwxrwxrwx 1 root root      12 Oct 29 13:46 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 5697416 Oct 29 13:46 redis-server
[root@redis bin]# cd ..
[root@redis redis]# ll
total 84
-rw-r--r-- 1 root root     0 Oct 29 21:31 appendonly.aof   ##aof是空的
drwxr-xr-x 2 root root   150 Oct 29 21:28 bin
-rw-r--r-- 1 root root 85573 Oct 29 21:30 redis.conf

当RDB和AOF同时存在时，系统默认优先读取AOF的数据。

3.AOF的备份恢复

1>在redis中添加4个键值 

[root@redis bin]# ./redis-cli -h 127.0.0.1
127.0.0.1:6379> set aa 11
OK
127.0.0.1:6379> set bb 22
OK
127.0.0.1:6379> set cc 33
OK
127.0.0.1:6379> set dd 44
OK
127.0.0.1:6379>exit

[root@redis redis]# ll
total 92
-rw-r--r-- 1 root root   197 Oct 29 21:39 appendonly.aof    ##查看数据已经被持久化
drwxr-xr-x 2 root root   150 Oct 29 21:28 bin
-rw-r--r-- 1 root root   122 Oct 29 21:40 dump.rdb
-rw-r--r-- 1 root root 85573 Oct 29 21:39 redis.conf
[root@redis redis]#

2>AOF的备份恢复

##查看redis的Pid,并将redis关闭
[root@redis bin]# ps -ef |grep redis    
root      31634      1  0 21:44 ?        00:00:00 /usr/local/redis/bin/redis-server 127.0.0.1:6379
root      31688  30723  0 21:45 pts/0    00:00:00 grep --color=auto redis
[root@redis bin]# kill -9 31634

##将aof文件改名
[root@redis bin]# mv appendonly.aof appendonly.aof.bak

##重新启动redis，查看数据是否存在
[root@redis bin]# /usr/local/redis/bin/redis-server /usr/local/redis/redis.conf
[root@redis bin]# ./redis-cli -h 127.0.0.1
127.0.0.1:6379> keys *       ##发现已经为空
(empty array)
127.0.0.1:6379> exit

##重新恢复aof文件
[root@redis bin]# mv appendonly.aof.bak appendonly.aof
mv: overwrite ‘appendonly.aof’? y  ##覆盖
[root@redis bin]# ll
total 18468
-rw-r--r-- 1 root root     139 Oct 29 21:45 appendonly.aof
-rw-r--r-- 1 root root     122 Oct 29 21:45 dump.rdb
-rwxr-xr-x 1 root root  738264 Oct 29 13:46 redis-benchmark
-rwxr-xr-x 1 root root 5697416 Oct 29 13:46 redis-check-aof
-rwxr-xr-x 1 root root 5697416 Oct 29 13:46 redis-check-rdb
-rwxr-xr-x 1 root root 1065840 Oct 29 13:46 redis-cli
lrwxrwxrwx 1 root root      12 Oct 29 13:46 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 5697416 Oct 29 13:46 redis-server

##重新启动redis
[root@redis bin]# ps -ef |grep redis
root      31727      1  0 21:46 ?        00:00:00 /usr/local/redis/bin/redis-server 127.0.0.1:6379
[root@redis bin]# kill 31727
[root@redis bin]# /usr/local/redis/bin/redis-server /usr/local/redis/redis.conf

##查看数据，已经恢复
[root@redis bin]# ./redis-cli -h 127.0.0.1
127.0.0.1:6379> keys *
1) "cc"
2) "dd"
3) "aa"
4) "bb"

4.AOF的修复

AOF文件一旦遇到损坏，我们可以利用redis自带的redis-check-aof这个功能进行恢复

1>模拟破坏appendonly.aof文件

vim appendonly.aof打开文件
set
$2
cc
$2
33
*3
$3
set
$2
dd
$2
44
hello       ##添加这一行数据，模拟损坏的场景

2>重新启动redis

[root@redis bin]# /usr/local/redis/bin/redis-server /usr/local/redis/redis.conf
[root@redis bin]# ./redis-cli -h 127.0.0.1
Could not connect to Redis at 127.0.0.1:6379: Connection refused   ##连接失败
not connected>

3>修复

[root@redis bin]# ./redis-check-aof --fix appendonly.aof
0x              8b: Expected prefix '*', got: 'h'        ##提示有异常
AOF analyzed: size=146, ok_up_to=139, diff=7
This will shrink the AOF from 146 bytes, with 7 bytes, to 139 bytes
Continue? [y/N]: y                  ##按Y
Successfully truncated AOF          ##提示修复成功

4>再次重启redis

[root@redis bin]# /usr/local/redis/bin/redis-server /usr/local/redis/redis.conf
[root@redis bin]# ./redis-cli -h 127.0.0.1
127.0.0.1:6379> keys *     ##看到数据又恢复了。
1) "aa"
2) "cc"
3) "dd"
4) "bb"
127.0.0.1:6379>

5>AOF的fsync的策略

1)always：每次写入一条数据，就立即将这个数据对应的写日志fsync到磁盘上去，性能非常的差，吞吐量非常低，如果非要保证redis不能丢失数据，那就只能这样子了。

2)everysec：每秒将os cache中的数据fsync到磁盘，这个最常用，并且redis默认也是这个策略，生产环境一般也是这么配置，性能也很高，QPS可达到上万。

3)no：仅仅将数据刷入到os cache中就不管了，然后就只能靠os cache自己的刷盘策略，时不时的将os cache中的数据刷入磁盘

6.rewrite的策略

 AOF是以不断向文件追加操作记录，当定义 x=100，修改为x=200，业务调整又把x删除 del x，但这些操作记录都会记录在AOF文件，造成AOF文件记录信息庞大且无用记录太大

AOF rewrite功能：将一些重复的，无用的，过时的数据进行整理合并的，过期的数据重新写入一个新的AOF文件，从而节约AOF备份占用的硬盘空间，也能加速恢复过程；可以手动执行bgrewriteaof 触发AOF，或定义自动rewrite策

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

 该策略配置的意思是：如果上一次rewrite之后AOF文件是128M，然后就会接着128M继续写，如果发现增长的比例，超过之前大小的100%，也就是256M，那么就会触发一次rewrite，但是在触发之前还有和min-size的64mb比较一下大小，如果大于这个最小值，才触发。

 1>rewrite的工作流程

1）redis fork一个子进程。
2）子进程基于当前内存中的数据，构建日志，开始往一个新的临时的AOF文件中写入日志。
3）redis主进程，接收到client新的写操作指令后，在内存中写入日志，同时新的日志指令也会在旧的AOF日志文件中写入。
4）子进程写完新的日志文件之后，redis主进程将内存中新写入的日志指令信息追加到这个新的AOF文件中。
5）用新的AOF文件替换旧的文件。

7.AOF的持久化过程

 1)客户端的请求写命令会被 append 追加到 AOF 缓冲区内
2)AOF缓冲区根据 AOF持久化策路[always,everysec,no]将操作 sync 同步到磁盘的AOF 文件中
3)AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件rewrite 重写，压缩AOF 文件容量
4)Redis 服务重启时，会重新 load 加载AOF 文件中的写操作达到数据恢复的目的

8.AOF的优缺点

1>优点

1）数据备份机制更高，数据安全性好
2）文本可读，可以操作AOF文件进行数据修复

2>缺点

1）比RDB占用更多的磁盘空间
2）恢复备份的速度比RDB慢
3）每次都做读写同步的话，性能压力比较大