NoSQL之【Redis】学习（三）：Redis持久化 Snapshot和AOF说明

2024-05-27 20:53:07 98

本文内容纲要：

一、对Redis持久化的探讨与理解

redis是一个支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化。redis支持两种持久化方式，一种是Snapshot（RDB）<二进制文件>也是默认方式，另一种是Appendonlyfile（AOF）的方式。

我们应该明确持久化的数据有什么用，答案是用于重启后的数据恢复。Redis是一个内存数据库，无论是RDB还是AOF，都只是其保证数据恢复的措施。所以Redis在利用RDB和AOF进行恢复的时候，都会读取RDB或AOF文件，重新加载到内存中。

RDB就是Snapshot快照存储，是默认的持久化方式。即按照一定的策略周期性的将数据保存到磁盘。对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。Redis支持将当前数据的快照存成一个数据文件的持久化机制。而一个持续写入的数据库如何生成快照呢。Redis借助了fork命令的copyonwrite机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。

Client也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有client的请求，这种方式会阻塞所有client请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步脏数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘io操作，可能会严重影响性能。

Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的。当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件。这样在任何时候出现故障，Redis的RDB文件都总是可用的。并且Redis的RDB文件也是Redis主从同步内部实现中的一环:
第一次Slave向Master同步的实现是：
Slave向Master发出同步请求，Master先dump出rdb文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。
第二次以及以后的同步实现是：
Master将变量的快照直接实时依次发送给各个Slave。但不管什么原因导致Slave和Master断开重连都会重复以上两个步骤的过程。
Redis的主从复制是建立在内存快照的持久化基础上的，只要有Slave就一定会有内存快照发生。

快照持久化过程：

1.redis调用fork,现在有了子进程和父进程。

2.父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制（copyonwrite)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父
进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。

3.当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。

**不足：**就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了（因为刷写机制还没有发出）。RDB就是Snapshot快照存储，是默认的持久化方式。

相关参数：

1##############################APPENDONLYMODE###############################
2#是否开启AOF，默认关闭（no）
3appendonlyyes
4#指定AOF文件名
5appendfilenameappendonly.aof
6#Redis支持三种不同的刷写模式：
7#appendfsyncalways#每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。
8appendfsynceverysec#每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
9#appendfsyncno#完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。
10
11#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISKIO上的冲突。
12#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes
13no-appendfsync-on-rewriteyes
14#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
15auto-aof-rewrite-percentage100
16#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
17auto-aof-rewrite-min-size64mb

从上面看出，RDB和AOF操作都是顺序IO操作，性能都很高。而同时在通过RDB文件或者AOF日志进行数据库恢复的时候，也是顺序的读取数据加载到内存中。所以也不会造成磁盘的随机读。

到底选择什么呢？下面是来自官方的建议：
通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用RDB。
很多用户仅使用了AOF，但是我们建议，既然RDB可以时不时的给数据做个完整的快照，并且提供更快的重启，所以最好还是也使用RDB。
在数据恢复方面：
RDB的启动时间会更短，原因有两个：
一是RDB文件中每一条数据只有一条记录，不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。
另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作，所以在CPU消耗上要远小于AOF日志的加载。

注意：

上面说了RDB快照的持久化，需要注意：在进行快照的时候（save），fork出来进行dump操作的子进程会共享父进程的内存（真正的copy-on-write）。比如机器8G内存，Redis已经使用了6G内存，这时新操作100M的内存，save的话会再多生成100M（放到缓冲区里），总共进行RDB的时候会多出100M，既6.1G的内存。

目前，通常的设计思路是利用Replication机制来弥补aof、snapshot性能上的不足，达到了数据可持久化。即Master上Snapshot和AOF都不做，来保证Master的读写性能，而Slave上则同时开启Snapshot和AOF来进行持久化，保证数据的安全性。

二、对Redis持久化的测试

通过上面的理论对snapshot和aof有了一定的理解，下面开始进行一些测试：：
1、redis.conf基本配置:开启snapshot，关闭aof

1save9001
2save30010
3save6010000
4
5rdbcompressionno
6rdbchecksumno
7dbfilenamezhoujy.rdb
8dir/var/lib/redis
9
10appendonlyno

操作

1redis127.0.0.1:6379>keys*#查看0库下是否有key
2(emptylistorset)
3redis127.0.0.1:6379>setnamezhoujinyi#set操作
4OK
5redis127.0.0.1:6379>setsexman
6OK
7redis127.0.0.1:6379>setage27
8OK
9redis127.0.0.1:6379>keys*
101)"age"
112)"sex"
123)"name"
13redis127.0.0.1:6379>
14zhoujy@zhoujy:~$ls-lh/var/lib/redis/#rdb文件初始化大小
15总用量4.0K
16-rw-rw----1redisredis182013-05-2516:19zhoujy.rdb
17zhoujy@zhoujy:~$redis
18redis127.0.0.1:6379>save#保存，进行持久化，每执行一次save，会在日至里面记录一条：“*DBsavedondisk”
19OK
20redis127.0.0.1:6379>
21zhoujy@zhoujy:~$ls-lh/var/lib/redis/#文件大小改变，数据写入文件进行了持久化
22总用量4.0K
23-rw-rw----1redisredis522013-05-2516:20zhoujy.rdb
24
25验证持久化，重启redis：
26
27redis127.0.0.1:6379>keys*
281)"name"
292)"age"
303)"sex"
31redis127.0.0.1:6379>setaddresshangzhou#key没有被保存就重启了
32OK
33redis127.0.0.1:6379>
34zhoujy@zhoujy:~$sudo/etc/init.d/redis-serverrestart
35Stoppingredis-server:redis-server.
36Startingredis-server:redis-server.
37zhoujy@zhoujy:~$redis
38redis127.0.0.1:6379>keys*#发现刚才没有被保存的key也被持久化了，怎么回事？
391)"name"
402)"address"
413)"sex"
424)"age"
43redis127.0.0.1:6379>
44
45查看日志，看看日志里面有什么信息：
46
47[21154]25May16:28:12.122#Userrequestedshutdown...
48[21154]25May16:28:12.122*SavingthefinalRDBsnapshotbeforeexiting.
49[21154]25May16:28:12.165*DBsavedondisk
50[21154]25May16:28:12.165*Removingthepidfile.
51[21154]25May16:28:12.165*Removingtheunixsocketfile.
52[21154]25May16:28:12.165#Redisisnowreadytoexit,byebye...
53
54从日志里面得到了解释，正常关闭redis，他会自己在关闭前执行save命令。那异常关闭呢？用kill的效果和上面一样，属于正常关闭。只能用kill-9才行：
54
55redis127.0.0.1:6379>keys*
561)"age"
572)"name"
583)"sex"
594)"address"
60redis127.0.0.1:6379>setcompanydxy
61OK
62redis127.0.0.1:6379>keys*
631)"name"
642)"sex"
653)"age"
664)"address"
675)"company"
68redis127.0.0.1:6379>#key没有被保存就重启了
69zhoujy@zhoujy:~$sudokill-921250
70zhoujy@zhoujy:~$redis
71CouldnotconnecttoRedisat127.0.0.1:6379:Connectionrefused
72notconnected>
73zhoujy@zhoujy:~$sudo/etc/init.d/redis-serverstart
74Startingredis-server:redis-server.
75zhoujy@zhoujy:~$redis
76redis127.0.0.1:6379>keys*#company没有被持久化，数据丢失，重启日志里没有“*DBsavedondisk”信息
771)"sex"
782)"age"
793)"address"
804)"name"
81redis127.0.0.1:6379>

总结1：从上面的结果看出，开启RDB持久化，在满足save条件、手动save、正常关闭的时候数据都会被持久化，而异常关闭终止的时候数据会丢失。

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

1#save9001
2#save30010
3#save6010000
4rdbcompressionno
5rdbchecksumno
6dbfilenamezhoujy.rdb
7dir/var/lib/redis
8
9appendonlyno

操作

1redis127.0.0.1:6379>keys*#查看0库下是否有key
2(emptylistorset)
3redis127.0.0.1:6379>setnamezhoujinyi#set操作
4OK
5redis127.0.0.1:6379>setsexman
6OK
7redis127.0.0.1:6379>setage27
8OK
9redis127.0.0.1:6379>save#保存，进行持久化，即使没有开始snapshot，执行save命令一样可以持久化，不手动的触发永远不会持久化。
10OK#每执行一次save，会在日志里面记录一条：“*DBsavedondisk”
11redis127.0.0.1:6379>setaddresshangzhou#set操作，但不save，正常重启
12OK
13redis127.0.0.1:6379>
14zhoujy@zhoujy:~$sudo/etc/init.d/redis-serverrestart#正常重启
15[sudo]passwordforzhoujy:
16Stoppingredis-server:redis-server.
17Startingredis-server:redis-server.
18zhoujy@zhoujy:~$redis
19redis127.0.0.1:6379>keys*#发现刚才没有被保存的key丢失了
201)"sex"
212)"name"
223)"age"
23redis127.0.0.1:6379>

总结2：从上面的结果看出，关闭持久化，只有在手动save的时候数据都会被持久化，正常关闭的时候数据丢失。要是从一开始到关闭写入数据的期间没有手动save，则数据全部丢失！既然能手动save间接的说明了快照一直都存在，所以不能说是禁止snapshot，应该是禁止自动snapshot功能。

通过1，2验证了之前说的：一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，下面看看AOF。

3、redis.conf基本配置:关闭snapshot，开启aof

1#save9001
2#save30010
3#save6010000
4
5appendonlyyes
6appendfilenamezhoujy.aof
7#appendfsyncalways
8appendfsynceverysec
9#appendfsyncno
10
11no-appendfsync-on-rewriteno
12auto-aof-rewrite-min-size64mb

操作

1#重启数据库之前有3个key：
2redis127.0.0.1:6379>keys*
31)"sex"
42)"age"
53)"name"
6#修改开启AOF参数，重启数据库：
7zhoujy@zhoujy:~$ls-lh/var/lib/redis/
8总用量4.0K
9-rw-r-----1redisredis02013-05-2517:41appendonly.aof#aof持久化已经开启，0字节大小
10-rw-rw----1redisredis522013-05-2517:34zhoujy.rdb
11
12redis127.0.0.1:6379>keys*#数据库里面没有记录？之前还有3个key，Why？
13(emptylistorset)
14redis127.0.0.1:6379>
15
16#查看日志：
17*DBloadedfromappendonlyfile:0.000seconds
18发现是从0字节的aof文件里面同步数据，为什么不同步rdb的数据？原来redis代码里面写好了优先级，AOF>RDB
19
20redis.c里的代码如下：
21
22voidloadDataFromDisk(void){
23longlongstart=ustime();
24if(server.aof_state==REDIS_AOF_ON){
25if(loadAppendOnlyFile(server.aof_filename)==REDIS_OK)
26redisLog(REDIS_NOTICE,"DBloadedfromappendonlyfile:%.3fseconds",(float)(ustime()-start)/1000000);
27}else{
28if(rdbLoad(server.rdb_filename)==REDIS_OK){
29redisLog(REDIS_NOTICE,"DBloadedfromdisk:%.3fseconds",
30(float)(ustime()-start)/1000000);
31}elseif(errno!=ENOENT){
32redisLog(REDIS_WARNING,"FatalerrorloadingtheDB:%s.Exiting.",strerror(errno));
33exit(1);
34}
35}
36}

这里需要注意的是:当中途开启AOF，重启让他生效的时候，千万不能再让他第2次正常重启了。因为第一次重启让aof生效的时候，启动redis已经读取这个文件了，导致此时的redis数据为空的（优先级）。要是再重启的，则会把这个空的数据save到RDB文件，这样导致RDB原有的数据被替换，导致数据丢失。所以一定要小心，为了避免悲剧的发生，当要重启redis的时候最好都备份下RDB文件。

1redis127.0.0.1:6379>keys*
2(emptylistorset)
3redis127.0.0.1:6379>setnamezhoujinyi
4OK
5redis127.0.0.1:6379>save
6OK
7
8#开启aof参数，重启redis生效（第一次重启）
9root@m2:/var/lib/redis#/etc/init.d/redis-serverrestart
10Stoppingredis-server:redis-serverstop!.
11Startingredis-server:redis-serverstart!
12root@m2:/var/lib/redis#ls-lh#生成aof文件，已经生效
13总用量4.0K
14-rw-r-----1rootroot05月2601:12appendonly.aof
15-rw-rw----1rootroot365月2601:12dump.rdb
16
17redis127.0.0.1:6379>keys*#如上面所说的优先级原因:aof>rdb，结果为空
18(emptylistorset)
19
20#再重启（第2次正常重启），把上面空的结果save到了RDB，数据丢失。此时的db是空的，日志记录"*DBsavedondisk"
21root@m2:/var/lib/redis#/etc/init.d/redis-serverrestart
22Stoppingredis-server:redis-serverstop!.
23Startingredis-server:redis-serverstart!
24
25root@m2:/var/lib/redis#ls-lh#数据已经被初始化了，数据丢失。
26总用量4.0K
27-rw-r-----1rootroot05月2601:12appendonly.aof
28-rw-rw----1rootroot185月2601:13dump.rdb
29redis127.0.0.1:6379>keys*
30(emptylistorset)

这里就有一个问题，比如在用redis的时候，刚开始只开启RDB的持久方式，AOF没有开启，在跑一段时间之后想开启AOF，那如何把RDB的数据直接写到AOF文件呢？有2种方法：
①:在开启AOF之前，先执行bgrewriteaof，再重启。

1redis127.0.0.1:6379>keys*#查看是否有数据
2(emptylistorset)
3redis127.0.0.1:6379>setnamezhoujinyi#生成数据
4OK
5redis127.0.0.1:6379>setsexman
6OK
7redis127.0.0.1:6379>setage27
8OK
9redis127.0.0.1:6379>keys*
101)"name"
112)"sex"
123)"age"
13redis127.0.0.1:6379>bgsave#保存数据
14Backgroundsavingstarted
15redis127.0.0.1:6379>keys*
161)"name"
172)"sex"
183)"age"
19root@m2:/var/lib/redis#ls-lh#只有一个RDB文件，没有AOF文件
20总用量4.0K
21-rw-rw----1rootroot525月2523:48dump.rdb
22
23redis127.0.0.1:6379>bgrewriteaof#执行合并重写功能，生成AOF文件
24Backgroundappendonlyfilerewritingstarted
25
26root@m2:/var/lib/redis#ls-lh#AOF文件生成成功
27总用量8.0K
28-rw-rw----1rootroot1225月2523:49appendonly.aof
29-rw-rw----1rootroot525月2523:48dump.rdb
30#这时候去打开redis.conf文件中的aof参数（appendonlyyes），重启生效。
31root@m2:/var/lib/redis#/etc/init.d/redis-serverrestart
32Stoppingredis-server:redis-serverstop!
33Startingredis-server:redis-serverstart!
34
35#日志里面出现：*DBloadedfromappendonlyfile:0.000seconds
36
37redis127.0.0.1:6379>keys*#数据还在
381)"sex"
392)"name"
403)"age"

②:利用CONFIGGET/SET的方法动态修改配置文件，和①比少了重启的操作。

1redis127.0.0.1:6379>setnamezhoujinyi
2OK
3redis127.0.0.1:6379>setsexman
4OK
5redis127.0.0.1:6379>setage27
6OK
7redis127.0.0.1:6379>keys*
81)"age"
92)"name"
103)"sex"
11redis127.0.0.1:6379>BGSAVE
12Backgroundsavingstarted
13redis127.0.0.1:6379>
14
15root@m2:/var/lib/redis#ls-lh#只有rdb文件
16总用量4.0K
17-rw-rw----1rootroot525月2600:09dump.rdb
18
19#动态修改参数，把aof功能开启：appendonlyyes
20
21redis127.0.0.1:6379>CONFIGGETappend*#在线查看参数
221)"appendonly"
232)"no"
243)"appendfsync"
254)"everysec"
26redis127.0.0.1:6379>CONFIGSETappendonlyyes#动态修改参数
27OK
28redis127.0.0.1:6379>CONFIGGETappend*
291)"appendonly"
302)"yes"
313)"appendfsync"
324)"everysec"
33redis127.0.0.1:6379>
34
35root@m2:/var/lib/redis#ls-lh#aof文件已经生成，并且有数据（同步rdb）。
36总用量8.0K
37-rw-rw----1rootroot1225月2600:10appendonly.aof
38-rw-rw----1rootroot525月2600:09dump.rdb
39
40#日志里面的信息：*Backgroundappendonlyfilerewritingstartedbypid3165
41#因为参数是动态修改的，在重启之后会失效，所以在维护的时候修改redis.conf文件的参数即可。

**总结3：**从上面的结果看出，redis重启载入数据的时候，读取aof的文件要先于rdb文件，所以尽量一开始开启aof选项，不要在中途开启。通过日志可以很清楚的知道redis通过那个文件来取数据的：
RDB:*DBloadedfromdisk:0.000seconds
AOF：*DBloadedfromappendonlyfile:0.000seconds
保存数据则是：
RDB：*DBsavedondisk
AOF:*Callingfsync()ontheAOFfile.

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

1save9001
2save30010
3save6010000
4
5appendonlyyes
6appendfilenamezhoujy.aof
7#appendfsyncalways
8appendfsynceverysec
9#appendfsyncno
10
11no-appendfsync-on-rewriteno
12auto-aof-rewrite-min-size64mb

操作

1#同时开启这2个参数，在日志里面会记录:
2*Callingfsync()ontheAOFfile.
3*DBsavedondisk
4
5redis127.0.0.1:6379>keys*
6(emptylistorset)
7redis127.0.0.1:6379>setnamezhoujinyi
8OK
9redis127.0.0.1:6379>setage27
10OK
11redis127.0.0.1:6379>setsexman
12OK
13redis127.0.0.1:6379>keys*
141)"name"
152)"age"
163)"sex"
17
18root@m2:/var/lib/redis#ls-lh#aof,rdb2个文件已经生成，并且aof文件大小根据操作命令实时增加，而rbd需要手动save或则到了刷写机制的阀值才增加
19总用量8.0K
20-rw-r-----1rootroot1225月2600:39appendonly.aof
21-rw-rw----1rootroot185月2600:37dump.rdb
22
23redis127.0.0.1:6379>save#保存快照
24OK
25
26root@m2:/var/lib/redis#ls-lh#rdb文件大小增加
27总用量8.0K
28-rw-r-----1rootroot1365月2600:41appendonly.aof
29-rw-rw----1rootroot525月2600:41dump.rdb
30
31redis127.0.0.1:6379>flushall#清除所有数据
32OK
33
34root@m2:/var/lib/redis#ls-lh#数据清除之后，rdb文件大小初始化了，而aof文件却增加了，Why？
35总用量8.0K
36-rw-r-----1rootroot1545月2600:43appendonly.aof
37-rw-rw----1rootroot185月2600:43dump.rdb
38#原来aof文件记录的是修改数据的操作，所以文件是追加形式的，flushall命令被追加到最后。
39
40root@m2:/var/lib/redis#/etc/init.d/redis-serverrestart#重启，看看通过aof的载入能否被读取到？
41Stoppingredis-server:redis-serverstop!.
42Startingredis-server:redis-serverstart!
43root@m2:/var/lib/redis#ls-lh#aof文件大小不变，重启不能初始化aof文件
44总用量8.0K
45-rw-r-----1rootroot1545月2600:43appendonly.aof
46-rw-rw----1rootroot185月2600:45dump.rdb
47
48redis127.0.0.1:6379>keys*#日志里面记录“*DBloadedfromappendonlyfile:0.012seconds”，但没有数据，说明aof确实被初始化了。
49(emptylistorset)
50
51#因为数据都已经被清除了，想让aof文件大小也初始化掉，该如何操作呢？
52很简单：
53redis127.0.0.1:6379>bgrewriteaof#让aof合并重写，因为aof文件的最后一条记录的flushall操作，前面的记录都无效了，合并所有操作之后就初始化了。
54Backgroundappendonlyfilerewritingstarted
55redis127.0.0.1:6379>
56
57root@m2:/var/lib/redis#ls-lh#aof文件被初始化
58总用量4.0K
59-rw-rw----1rootroot05月2600:51appendonly.aof
60-rw-rw----1rootroot185月2600:45dump.rdb

通过上面的这些测试，已经说明RDB和AOF他们的操作方式，以及如重启时的载入，重启时将按照以下优先级恢复数据到内存：
•如果只配置AOF,重启时加载AOF文件恢复数据。
•如果同时配置了RBD和AOF,启动是只加载AOF文件恢复数据。
•如果只配置RBD,启动是讲加载dump文件恢复数据。

为了防止悲剧的发生，我们应该进行备份。

三、对Redis备份

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

1#redisA:A上生成测试数据
2redis127.0.0.1:6379>setnamezhoujinyi
3OK
4redis127.0.0.1:6379>setsexman
5OK
6redis127.0.0.1:6379>setage17
7OK
8redis127.0.0.1:6379>keys*
91)"age"
102)"name"
113)"sex"
12redis127.0.0.1:6379>bgsave
13Backgroundsavingstarted
19#redisB:B上没有数据
20redis127.0.0.1:6380>keys*
21(emptylistorset)
22
23#复制A的文件到B（rdb和aof文件）
24cpredis/*redis2/
25#修改权限
26chown-Rredis.redis*
27#重启B
28zhoujy@m2:~$redis-p6380shutdown
29zhoujy@m2:~$redis-p6380
30#还原成功
31redis127.0.0.1:6380>keys*
321)"sex"
332)"name"
343)"age"

以上完成。

本文内容总结：

原文链接：https://www.cnblogs.com/zhoujinyi/archive/2013/05/26/3098508.html

NoSQL之【Redis】学习（三）：Redis持久化 Snapshot和AOF说明

本文内容纲要：

热门推荐

随机推荐