Redis 持久化之RDB和AOF-阿里云开发者社区

开发者社区> dasein58> 正文

Redis 持久化之RDB和AOF

简介:   Redis 有两种持久化方案,RDB (Redis DataBase)和 AOF (Append Only File)。如果你想快速了解和使用RDB和AOF,可以直接跳到文章底部看总结。本章节通过配置文件,触发快照的方式,恢复数据的操作,命令操作演示,优缺点来学习 Redis 的重点知识持久化。   RDB 详解   RDB 是 Redis 默认的持久化方案。在指定的时间间隔内,执行指定次数的写操作,则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。   从配置文件了解RDB
+关注继续查看

  Redis 有两种持久化方案,RDB (Redis DataBase)和 AOF (Append Only File)。如果你想快速了解和使用RDB和AOF,可以直接跳到文章底部看总结。本章节通过配置文件,触发快照的方式,恢复数据的操作,命令操作演示,优缺点来学习 Redis 的重点知识持久化。

  RDB 详解

  RDB 是 Redis 默认的持久化方案。在指定的时间间隔内,执行指定次数的写操作,则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。

  从配置文件了解RDB

  打开 redis.conf 文件,找到 SNAPSHOTTING 对应内容

  1 RDB核心规则配置(重点)

  save

  # save ""

  save 900 1

  save 300 10

  save 60 10000

  解说:save <指定时间间隔> <执行指定次数更新操作>,满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改,300秒内有10个更改以及60秒内有10000个更改,则将内存中的数据快照写入磁盘。

  若不想用RDB方案,可以把 save "" 的注释打开,下面三个注释。

  2 指定本地数据库文件名,一般采用默认的 dump.rdb

  dbfilename dump.rdb

  3 指定本地数据库存放目录,一般也用默认配置

  dir ./

  4 默认开启数据压缩

  rdbcompression yes

  解说:配置存储至本地数据库时是否压缩数据,默认为yes。Redis采用LZF压缩方式,但占用了一点CPU的时间。若关闭该选项,但会导致数据库文件变的巨大。建议开启。

  触发RDB快照

  1 在指定的时间间隔内,执行指定次数的写操作

  2 执行save(阻塞, 只管保存快照,其他的等待) 或者是bgsave (异步)命令

  3 执行flushall 命令,清空数据库所有数据,意义不大。

  4 执行shutdown 命令,保证服务器正常关闭且不丢失任何数据,意义...也不大。

  通过RDB文件恢复数据

  将dump.rdb 文件拷贝到redis的安装目录的bin目录下,重启redis服务即可。在实际开发中,一般会考虑到物理机硬盘损坏情况,选择备份dump.rdb 。可以从下面的操作演示中可以体会到。

  RDB 的优缺点

  优点:

  1 适合大规模的数据恢复。

  2 如果业务对数据完整性和一致性要求不高,RDB是很好的选择。

  缺点:

  1 数据的完整性和一致性不高,因为RDB可能在最后一次备份时宕机了。

  2 备份时占用内存,因为Redis 在备份时会独立创建一个子进程,将数据写入到一个临时文件(此时内存中的数据是原来的两倍哦),最后再将临时文件替换之前的备份文件。

  所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

  操作演示

  [root@itdragon bin]# vim redis.conf

  save 900 1

  save 120 5

  save 60 10000

  [root@itdragon bin]# ./redis-server redis.conf

  [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379

  127.0.0.1:6379> keys *

  (empty list or set)

  127.0.0.1:6379> set key1 value1

  OK

  127.0.0.1:6379> set key2 value2

  OK

  127.0.0.1:6379> set key3 value3

  OK

  127.0.0.1:6379> set key4 value4

  OK

  127.0.0.1:6379> set key5 value5

  OK

  127.0.0.1:6379> set key6 value6

  OK

  127.0.0.1:6379> SHUTDOWN

  not connected> QUIT

  [root@itdragon bin]# cp dump.rdb dump_bk.rdb

  [root@itdragon bin]# ./redis-server redis.conf

  [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379

  127.0.0.1:6379> FLUSHALL

  OK

  127.0.0.1:6379> keys *

  (empty list or set)

  127.0.0.1:6379> SHUTDOWN

  not connected> QUIT

  [root@itdragon bin]# cp dump_bk.rdb dump.rdb

  cp: overwrite `dump.rdb'? y

  [root@itdragon bin]# ./redis-server redis.conf

  [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379

  127.0.0.1:6379> keys *

  1) "key5"

  2) "key1"

  3) "key3"

  4) "key4"

  5) "key6"

  6) "key2"

  第一步:vim 修改持久化配置时间,120秒内修改5次则持久化一次。

  第二步:重启服务使配置生效。

  第三步:分别set 5个key,过两分钟后,在bin的当前目录下会自动生产一个dump.rdb文件。(set key6 是为了验证二手游戏账号买号shutdown有触发RDB快照的作用)

  第四步:将当前的dump.rdb 备份一份(模拟线上工作)。

  第五步:执行FLUSHALL命令清空数据库数据(模拟数据丢失)。

  第六步:重启Redis服务,恢复数据.....咦????( ′? `)。数据是空的????这是因为FLUSHALL也有触发RDB快照的功能。

  第七步:将备份的 dump_bk.rdb 替换 dump.rdb 然后重新Redis。

  注意点:SHUTDOWN 和 FLUSHALL 命令都会触发RDB快照,这是一个坑,请大家注意。

  其他命令:

  keys * 匹配数据库中所有 keysave 阻塞触发RDB快照,使其备份数据FLUSHALL 清空整个 Redis 服务器的数据(几乎不用)SHUTDOWN 关机走人(很少用)AOF 详解

  AOF :Redis 默认不开启。它的出现是为了弥补RDB的不足(数据的不一致性),所以它采用日志的形式来记录每个写操作,并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

  从配置文件了解AOF

  打开 redis.conf 文件,找到 APPEND ONLY MODE 对应内容

  1 redis 默认关闭,开启需要手动把no改为yes

  appendonly yes

  2 指定本地数据库文件名,默认值为 appendonly.aof

  appendfilename "appendonly.aof"

  3 指定更新日志条件

  # appendfsync always

  appendfsync everysec

  # appendfsync no

  解说:

  always:同步持久化,每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好(慢,安全)

  everysec:出厂默认推荐,每秒异步记录一次(默认值)

  no:不同步

  4 配置重写触发机制

  auto-aof-rewrite-percentage 100

  auto-aof-rewrite-min-size 64mb

  解说:当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G,64M太小了。

  触发AOF快照

  根据配置文件触发,可以是每次执行触发,可以是每秒触发,可以不同步。

  根据AOF文件恢复数据

  正常情况下,将appendonly.aof 文件拷贝到redis的安装目录的bin目录下,重启redis服务即可。但在实际开发中,可能因为某些原因导致appendonly.aof 文件格式异常,从而导致数据还原失败,可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。从下面的操作演示中体会。

  AOF的重写机制

  前面也说到了,AOF的工作原理是将写操作追加到文件中,文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时,Redis就会对AOF文件的内容压缩。

  重写的原理:Redis 会fork出一条新进程,读取内存中的数据,并重新写到一个临时文件中。并没有读取旧文件(你都那么大了,我还去读你??? o(?Д?)っ傻啊!)。最后替换旧的aof文件。

  触发机制:当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。

  AOF 的优缺点

  优点:数据的完整性和一致性更高

  缺点:因为AOF记录的内容多,文件会越来越大,数据恢复也会越来越慢。

  操作演示

  [root@itdragon bin]# vim appendonly.aof

  appendonly yes

  [root@itdragon bin]# ./redis-server redis.conf

  [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379

  127.0.0.1:6379> keys *

  (empty list or set)

  127.0.0.1:6379> set keyAOf valueAof

  OK

  127.0.0.1:6379> FLUSHALL

  OK

  127.0.0.1:6379> SHUTDOWN

  not connected> QUIT

  [root@itdragon bin]# ./redis-server redis.conf

  [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379

  127.0.0.1:6379> keys *

  1) "keyAOf"

  127.0.0.1:6379> SHUTDOWN

  not connected> QUIT

  [root@itdragon bin]# vim appendonly.aof

  fjewofjwojfoewifjowejfwf

  [root@itdragon bin]# ./redis-server redis.conf

  [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379

  Could not connect to Redis at 127.0.0.1:6379: Connection refused

  not connected> QUIT

  [root@itdragon bin]# redis-check-aof --fix appendonly.aof

  'x 3e: Expected prefix '*', got: '

  AOF analyzed: size=92, ok_up_to=62, diff=30

  This will shrink the AOF from 92 bytes, with 30 bytes, to 62 bytes

  Continue? [y/N]: y

  Successfully truncated AOF

  [root@itdragon bin]# ./redis-server redis.conf

  [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379

  127.0.0.1:6379> keys *

  1) "keyAOf"

  第一步:修改配置文件,开启AOF持久化配置。

  第二步:重启Redis服务,并进入Redis 自带的客户端中。

  第三步:保存值,然后模拟数据丢失,关闭Redis服务。

  第四步:重启服务,发现数据恢复了。(额外提一点:有教程显示FLUSHALL 命令会被写入AOF文件中,导致数据恢复失败。我安装的是redis-4.0.2没有遇到这个问题)。

  第五步:修改appendonly.aof,模拟文件异常情况。

  第六步:重启 Redis 服务失败。这同时也说明了,RDB和AOF可以同时存在,且优先加载AOF文件。

  第七步:校验appendonly.aof 文件。重启Redis 服务后正常。

  补充点:aof 的校验是通过 redis-check-aof 文件,那么rdb 的校验是不是可以通过 redis-check-rdb 文件呢???

  总结Redis 默认开启RDB持久化方式,在指定的时间间隔内,执行指定次数的写操作,则将内存中的数据写入到磁盘中。RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。Redis 需要手动开启AOF持久化方式,默认是每秒将写操作日志追加到AOF文件中。AOF 的数据完整性比RDB高,但记录内容多了,会影响数据恢复的效率。Redis 针对 AOF文件大的问题,提供重写的瘦身机制。若只打算用Redis 做缓存,可以关闭持久化。若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份,留一后手。AOF出问题了,还有RDB。

  到这里Redis 的持久化就介绍完了,有什么不对的地方可以指出。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
7842 0
redis 数据备份持久化方案
原文:redis 数据备份持久化方案 本文链接:http://www.cnblogs.com/zhenghongxin/p/9050219.html 使用两种备份方案 备份方案选择RDB和AOF同时进行备份,必须打开AOF的持久化机制,除非能接受在故障环境下丢失几分钟的数据。
823 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
9564 0
redis aof持久化
redis aof缓存数据结构  redis用于存储aof内存数据的数据结构是aof_buf数据结构,所有数据先追加到内存的aof_buf后,再通过定时任务检查是否能够持久化到磁盘文件当中。
774 0
Redis专题-Redis持久化&持久化方式&持久化意义
课程大纲 1、Redis持久化的意义 2、如何应对故障的发生 3、持久化方式-RDB 4、持久化方式-AOF 5、RDB持久化机制的优点与缺点 6、AOF持久化机制的优点与缺点 7、RDB和AOF到底该如何选择 1、Redis持久化的意义 redi...
1089 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
11225 0
Redis持久化存储
Redis是一个支持持久化的内存数据库,也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化。redis支持四种持久化方式,一是 Snapshotting(快照)也是默认方式;二是Append-only file(缩写aof)的方式;三是虚拟内存方式;四是diskstore方式。
845 0
+关注
735
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载