Redis的RDB和AOF

1.数据快照RDB

1.1原理

(1)RDB是将某一时刻的数据持久化到磁盘中,是一种快照的方式。

(2)redis在进行数据持久化的过程中,会先将数据写入到一个临时文件中,待持久化过程都结束了,才会用这个临时文件替换上次持久化好的文件。正是这种特性,让我们可以随时来进行备份,及时redis处于运行状态;

(3)对于RDB方式,redis会单独创建(fork)一个子进程来进行持久化,而主进程是不会进行任何IO操作的,这样就确保了redis极高的性能。

(4)如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。

如果你对数据的完整性非常敏感,那么RDB方式就不太适合你,因为即使你每5分钟都持久化一次,当redis故障时,仍然会有近5分钟的数据丢失。所以,redis还提供了另一种持久化方式,那就是AOF。

1.2生成快照的几种方法

手动触发:

(1)save命令用于创建当前数据库的备份,该命令将在 redis 安装目录dir下创建dump.rdb文件;

如果需要恢复数据,只需将备份文件dump.rdb移动到 redis 安装目录并启动服务即可。获取redis目录可以使用 config get dir命令

(2) bgsave在后台执行;

(3)shutdown save,关闭服务的时候,shutdown有两个选项,nosave|save,如果不加,默认是save;

自动触发:

(4)配置文件redis.conf中的设置:

save 900 1

save 300 10

save 60 10000

dbfilename  dump.rdb

1.3 使用rdb文件进行还原测试

注意:还原的时候需要关闭aof的功能,否则redis在启动的时候会加载appendonly.aof这个日志文件,这样恢复的就不是dump.rdb的内容了,而是应用的aof日志

#使用redis-benchmark加载测试数据,并关闭aof:

src/redis-benchmark -h 127.0.0.1 -p 6379  -n 200000 -c 20 -d 4 -k 1 --csv > redis_benchmart_$(date +%Y%m%d).log 2>&1

[[email protected] redis]# src/redis-cli

127.0.0.1:6379> config get dir

1) "dir"

2) "/usr/local/redis"

127.0.0.1:6379> config get appendonly

1) "appendonly"

2) "no"

127.0.0.1:6379> keys *

1) "key1"

2) "key2"

3) "key:__rand_int__"

4) "mylist"

5) "counter:__rand_int__"

127.0.0.1:6379> shutdown save

[[email protected] redis]# mv dump.rdb dump.rdb.bak

[[email protected] redis]# src/redis-server redis.conf

[[email protected] redis]# src/redis-cli

127.0.0.1:6379> keys *

(empty list or set)

127.0.0.1:6379> shutdown nosave

把备份的rdb文件放在指定位置,并重启redis,这样数据又恢复了

[[email protected] redis]# mv dump.rdb.bak dump.rdb

[[email protected] redis]# src/redis-server redis.conf

[[email protected] redis]# src/redis-cli

127.0.0.1:6379> keys *

1) "key:__rand_int__"

2) "mylist"

3) "key2"

4) "key1"

5) "counter:__rand_int__"

2.AOF(append only file)

2.1 AOF

(1)即只允许追加,不允许更改的文件

开启方法:appendonly yes

AOF方式是将执行过的写指令记录下来,在数据恢复时按照从前到后的顺序再将指令都执行一遍;

同样数据集的情况下,AOF文件要比RDB文件的体积大。而且,AOF方式的恢复速度也要慢于RDB方式。

我们通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作(如SET等),redis就会被追加到AOF文件的末尾。

默认的AOF持久化策略是每秒钟fsync一次(fsync是指把缓存中的写指令记录到磁盘中),因为在这种情况下,redis仍然可以保持很好的处理性能,即使redis故障,也只会丢失最近1秒钟的数据。

(2)如果在追加日志时,恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整,redis提供了redis-check-aof工具,可以用来进行日志修复:

  • Make a backup copy of your AOF file.
  • Fix the original file using the redis-check-aof tool that ships with Redis: $ redis-check-aof --fix appendonly.aof
  • Optionally use diff -u to check what is the difference between two files.
  • Restart the server with the fixed file.

(3)通过appendonly.aof文件进行还原测试

127.0.0.1:6379> config get appendonly

1) "appendonly"

2) "yes"

127.0.0.1:6379> mset key1 1 key2 2 key3 3

OK

127.0.0.1:6379> keys *

1) "key3"

2) "key1"

3) "key2"

[[email protected] redis]# cp appendonly.aof appendonly.aof.bak

127.0.0.1:6379> flushall

OK

127.0.0.1:6379> keys *

(empty list or set)

127.0.0.1:6379> shutdown

[[email protected] redis]# rm -rf appendonly.aof

[[email protected] redis]# mv appendonly.aof.bak appendonly.aof

[[email protected] redis]# src/redis-server redis.conf

[[email protected] redis]# src/redis-cli

127.0.0.1:6379> keys *

1) "key1"

2) "key2"

3) "key3"

2.2 aof文件的rewrite

(1)rewrite原理

因为采用了追加方式,如果不做任何处理的话,AOF文件会变得越来越大,为此,redis提供了AOF文件重写(rewrite)机制,即当AOF文件的大小超过所设定的阈值时,redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。假如我们调用了100次INCR指令,在AOF文件中就要存储100条指令,但这明显是很低效的,完全可以把这100条指令合并成一条SET指令,这就是重写机制的原理。

在进行AOF重写时,仍然是采用先写临时文件,全部完成后再替换的流程,所以断电、磁盘满等问题都不会影响AOF文件的可用性。

AOF方式的另一个好处,我们通过一个“场景再现”来说明。某同学在操作redis时,不小心执行了flushall,导致redis内存中的数据全部被清空了,只要redis配置了AOF持久化方式,且AOF文件还没有被重写(rewrite),我们就可以用最快的速度暂停redis并编辑AOF文件,将最后一行的FLUSHALL命令删除,然后重启redis,就可以恢复redis的所有数据到FLUSHALL之前的状态了。但是如果AOF文件已经被重写了,那就无法通过这种方法来恢复数据了。

(2)触发rewrite的方法

第一种方法:使用bgrewriteaof命令手动触发;

第二种方法:由配置文件控制

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

比如上边的参数设置的含义:当appendonly.aof为小于64M时,不会触发rewrite,当文件大64M,增长率达到100%,即为128M时,触发一次rewrite,这个时候redis记住文件rewrite之后的大小,假如为80M,只有等到文件再次涨到160M后,才会触发下一次,依次类推

3 总结:

官方推荐同时开启这两种备份策略,确保数据更加安全;

如果你的业务可以接受一定数据的丢失,更注重性能,可以只开启RDB;

如果只把redis作为一个缓存来用,则不需要开启RDB和AOF;

参考链接

https://redis.io/topics/persistence

原文地址:http://blog.51cto.com/darrenmemos/2147653

时间: 2024-10-08 02:06:41

Redis的RDB和AOF的相关文章

redis的 rdb 和 aof 持久化的区别 [转]

aof,rdb是两种 redis持久化的机制.用于crash后,redis的恢复. rdb的特性如下: Code: fork一个进程,遍历hash table,利用copy on write,把整个db dump保存下来.save, shutdown, slave 命令会触发这个操作.粒度比较大,如果save, shutdown, slave 之前crash了,则中间的操作没办法恢复. aof有如下特性: Code: 把写操作指令,持续的写到一个类似日志文件里.(类似于从postgresql等数

redis持久化RDB和AOF

Redis 持久化: 提供了多种不同级别的持久化方式:一种是RDB,另一种是AOF. RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot). AOF 持久化记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集. AOF 文件中的命令全部以 Redis 协议的格式来保存,新命令会被追加到文件的末尾. Redis 还可以在后台对 AOF 文件进行重写(rewrite),使得 AOF 文件的体积不会超出保存数据集状态所

Redis 持久化RDB与AOF

Redis 持久化: 提供了多种不同级别的持久化方式:一种是RDB,另一种是AOF. RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot). AOF 持久化记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集. AOF 文件中的命令全部以 Redis 协议的格式来保存,新命令会被追加到文件的末尾. Redis 还可以在后台对 AOF 文件进行重写(rewrite),使得 AOF 文件的体积不会超出保存数据集状态所

Redis持久化RDB、AOF

持久化的意思就是保存,保存到硬盘.第一次接触这个词是在几年前学习EF. 为什么要持久化 redis定义:Redis是一个开源(BSD许可),内存存储的数据结构服务器,可用作数据库,高速缓存和消息队列代理.它支持字符串.哈希表.列表.集合.有序集合,位图,hyperloglogs等数据类型.内置复制.Lua脚本.LRU收回.事务以及不同级别磁盘持久化功能,同时通过Redis Sentinel提供高可用,通过Redis Cluster提供自动分区. 可以看出redis是一个内存的数据库,但是如果re

Redis中RDB和AOF持久化区别和联系

RDB和AOF持久化   ?RDB持久化 RDB是什么? 原理是redis会单独创建(fork) 一个与当前进程一模一 样的子进程来进行持久化,这个子进程的所有数据(变量.环境变量,程序程序计数器等)都和原进程一模一 样,会先将数据写入到一个临时文件中,待持久化结束了,再用这个临时文件替换上次持久化好的文件,整个过程中,主进程不进行任何的io操作,这就确保了极高的性能 1.这个持久化文件在哪里 RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘.也是默认的持久化方式,这种方式是就是将

003.图解分析 redis 的 RDB 和 AOF 两种持久化机制的工作原理

目录 RDB AOF 小结 参考 我们已经知道对于一个企业级的 redis 架构来说,持久化是不可减少的 tip 牢记企业级 redis 集群架构是用来支撑海量数据.高并发.高可用 持久化主要是做灾难恢复.数据恢复,也可以归类到高可用的一个环节里面去 比如你 redis 整个挂了,redis 就不可用了,你要做的事情是让 redis 变得可用,尽快变得可用你会怎么做? 你会重启 redis,尽快让它对外提供服务,但是就像上一讲说,如果你没做数据备份,这个时候 redis 就算启动了,也不可用,数

004.redis 的 RDB 和 AOF 两种持久化机制的优劣势对比

目录 RDB 持久化机制的优点 RDB 持久化机制的缺点 AOF 持久化机制的优点 AOF 持久化机制的缺点 RDB 和 AOF 到底该如何选择 参考 RDB 持久化机制的优点 适合做冷备 RDB 会生成多个数据文件,每个数据文件都代表了某一个时刻中 redis 的数据,这种多个数据文件的方式,非常适合做冷备,可以将这种完整的数据文件发送到一些远程的安全存储上去,如云上,以预定好的备份策略来定期备份 redis 中的数据 性能影响小 能让 redis 对外提供的读写服务不受影响,因为 redis

redis的rdb与aof持久化机制

Redis提供了两种持久化方案:RDB持久化和AOF持久化,一个是快照的方式,一个是类似日志追加的方式 RDB快照持久化 RDB持久化是通过快照的方式,即在指定的时间间隔内将内存中的数据集快照写入磁盘.在创建快照之后,用户可以备份该快照,可以将快照复制到其他服务器以创建相同数据的服务器副本,或者在重启服务器后恢复数据.RDB是Redis默认的持久化方式 save 900 1 当时间到900秒时,如果至少有1个key发生变化,就会自动触发bgsave命令创建快照 save 300 10 当时间到3

redis的 rdb 和 aof 持久化的区别

aof,rdb是两种 redis持久化的机制.用于奔溃后,redis的恢复. rdb的特性如下: Code: fork一个进程,遍历hash table,利用copy on write,把整个db dump保存下来.save, shutdown, slave 命令会触发这个操作.粒度比较大,如果save, shutdown, slave 之前crash了,则中间的操作没办法恢复. aof有如下特性: Code: 把写操作指令,持续的写到一个类似日志文件里.(类似于从postgresql等数据库导