Redis 持久化之RDB和AOF详解
一、RDB 详解
RDB 是 Redis 默认的持久化方案。在指定的时间间隔内,执行指定次数的写操作,则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。
从配置文件了解RDB
打开 redis.conf 文件,找到 SNAPSHOTTING 对应内容
1 RDB核心规则配置(重点)
save <seconds> <changes>
# save ""
save
save
save
解释: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 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。
触发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
save
save
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p
127.0.0.1:> keys *
(empty list or set)
127.0.0.1:> set key1 value1
OK
127.0.0.1:> set key2 value2
OK
127.0.0.1:> set key3 value3
OK
127.0.0.1:> set key4 value4
OK
127.0.0.1:> set key5 value5
OK
127.0.0.1:> set key6 value6
OK
127.0.0.1:> 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
127.0.0.1:> FLUSHALL
OK
127.0.0.1:> keys *
(empty list or set)
127.0.0.1:> 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
127.0.0.1:> keys *
) "key5"
) "key1"
) "key3"
) "key4"
) "key6"
) "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 * 匹配数据库中所有 key
- save 阻塞触发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
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
127.0.0.1:> keys *
(empty list or set)
127.0.0.1:> set keyAOf valueAof
OK
127.0.0.1:> FLUSHALL
OK
127.0.0.1:> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p
127.0.0.1:> keys *
) "keyAOf"
127.0.0.1:> 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
Could not connect to Redis at 127.0.0.1:: Connection refused
not connected> QUIT
[root@itdragon bin]# redis-check-aof --fix appendonly.aof
'x 3e: Expected prefix '*', got: '
AOF analyzed: size=, ok_up_to=, diff=
This will shrink the AOF from bytes, with bytes, to 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
127.0.0.1:> keys *
) "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 的持久化就介绍完了,有什么不对的地方可以指出。
Redis 快速入门:http://www.cnblogs.com/itdragon/p/7897131.html
Redis 持久化之RDB和AOF详解的更多相关文章
- 【Redis】Redis 持久化之 RDB 与 AOF 详解
一.Redis 持久化 我们知道Redis的数据是全部存储在内存中的,如果机器突然GG,那么数据就会全部丢失,因此需要有持久化机制来保证数据不会一位宕机而丢失.Redis 为我们提供了两种持久化方案, ...
- Redis基础(三)Redis持久化:RDB与AOF
什么是Redis持久化? Redis是键值对的内存数据库,它将数据存储在内存里.客户端发送命令到服务器,再由服务器到内存里查找数据. 一旦Redis服务器进程退出,存储在内存里的数据就会丢失. 为了解 ...
- 详解Redis持久化(RDB和AOF)
详解Redis持久化(RDB和AOF) 什么是Redis持久化? Redis读写速度快.性能优越是因为它将所有数据存在了内存中,然而,当Redis进程退出或重启后,所有数据就会丢失.所以我们希望Red ...
- Redis 持久化之RDB和AOF
Redis 持久化之RDB和AOF Redis 有两种持久化方案,RDB (Redis DataBase)和 AOF (Append Only File).如果你想快速了解和使用RDB和AOF,可以直 ...
- redis持久化(RDB、AOF、混合持久化)
redis持久化(RDB.AOF.混合持久化) 1. RDB快照(snapshot) 在默认情况下, Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中. 你可以对 Redis ...
- [转载]Redis 持久化之RDB和AOF
原文链接:https://www.cnblogs.com/itdragon/p/7906481.html 温馨提示 在正式数据(当然是非生产环境啦)练习以下操作时,一定一定一定记得备份dump.rdb ...
- redis学习(四)redis持久化之RDB、AOF
redis是内存数据库,它把数据存储在内存中,这样在加快读取速度的同时也对数据安全性产生了新的问题,即当redis所在服务器发生宕机后,redis数据库里的所有数据将会全部丢失.为了解决这个问题,re ...
- 【Redis】Redis学习(七) Redis 持久化之RDB和AOF
Redis 持久化提供了多种不同级别的持久化方式:一种是RDB,另一种是AOF. RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot). AOF ...
- Redis持久化之RDB与AOF
1. Redis的持久化方式 Redis作为高效的缓存件,它的数据存放在内存中,如果没有配置持久化,那么数据会在重启后丢失,因此如果不是仅用Redis做缓存的话,需要开启Redis的持久化功能,将数据 ...
随机推荐
- python函数基础(函数的定义和调用)
函数的定义 python定义函数使用def关键字 return[表达式]语句用于退出函数,选择性的向调用方返回一个表达式,不带参数值的return语句返回none def 函数名(参数列表): 函数体 ...
- webpack 简单笔记(一)
安装部分不介绍了 (一)第一个最简单的demo,单入口,单文件 目录结构: webapck.config.js中代码: 'use strict' const path = require('path' ...
- JSONObjectSample
package com.egeniuss.platform.basic; import java.util.ArrayList; import java.util.HashMap; import ja ...
- netty 私有协议栈
通信协议从广义上区分,可以分为公有协议和私有协议.由于私有协议的灵活性,它往往会在某个公司或者组织内部使用,按需定制,也因为如此,升级起来会非常方便,灵活性好.绝大多数的私有协议传输层都基于TCP/I ...
- sqlite获取表字段
sqlite下能通过sqlite_master获取指定数据库的表信息和表结构 但是通过sqlite_master不能获取表字段的信息 如果需要获取指定表字段的所有信息 可以使用如下语法: PRAGMA ...
- 筛法求欧拉函数(poj2478
求1-n的欧拉函数的值 #include <iostream> #include <cstdio> #include <queue> #include <al ...
- JavaSE_10_IO流
1.1 什么是IO 把这种数据的传输,可以看做是一种数据的流动,按照流动的方向,以内存为基准,分为输入input 和输出output ,即流向内存是输入流,流出内存的输出流. 1.2 IO的分类 输入 ...
- React中的this.props.children
React this.props.children this.props对象的属性与组件的属性一一对应,但是有一个例外,就是this.props.children属性.它表示组件的所有子节点. var ...
- c语言学习笔记 - 结构体位域
在学习结构体的时候遇到了位域这个概念,位域主要是为了节省内存空间,比如用一个32位,4个字节的int存储一个开关变量时,会造成空间浪费,于是干脆就考虑在这个32划分不同的区域来存储数据,例如划出1位存 ...
- lvs + keepalived + nginx + tomcat高可用负载反向代理服务器配置(一) 简介
一. 为什么这样构架 1. 系统高可用性 2. 系统可扩展性 3. 负载均衡能力 LVS+keepalived能很好的实现以上的要求,keepalived提供健康检查,故障转移,提高系统的可用性!采用 ...