[TOC]
# 什么是redis的持久化
官网介绍:
英文:https://redis.io/topics/persistence
中文:http://www.redis.cn/topics/persistence.html
# Redis的RDB是什么
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里,Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到。
一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
备注解释:
--fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程
# Redis配置文件redis.conf中关于RDB的相关配置
首先贴出来配置信息
~~~
################################ SNAPSHOTTING ################################
#
# Save the DB on disk:
#
# save <seconds> <changes>
#
# Will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
#
# Note: you can disable saving completely by commenting out all "save" lines.
#
# It is also possible to remove all the previously configured save
# points by adding a save directive with a single empty string argument
# like in the following example:
#
# save ""
save 900 1
save 300 10
save 60 10000
# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes
# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes
# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes
# The filename where to dump the DB
dbfilename dump.rdb
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./
~~~
## 如何触发RDB快照
- 配置文件中默认的快照配置
~~~
save 900 1
save 300 10
save 60 10000
~~~
save 900 1 #刷新快照到硬盘中,必须满足两者要求才会触发,即900秒之后至少1个关键字发生变化。
save 300 10 #必须是300秒之后至少10个关键字发生变化。
save 60 10000 #必须是60秒之后至少10000个关键字发生变化。(以上3个选项都屏蔽,则rdb禁用)
~~~
stop-writes-on-bgsave-error yes #后台存储错误停止写。
rdbcompression yes #使用LZF压缩rdb文件。
rdbchecksum yes #存储和加载rdb文件时校验。
dbfilename dump.rdb #设置rdb文件名。
dir ./ #设置工作目录,rdb文件会写入该目录。
~~~
命令save或者是bgsave
SAVE:save时只管保存,其它不管,全部阻塞
BGSAVE:Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。可以通过lastsave
命令获取最后一次成功执行快照的时间
**注:执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义**
## 默认RDB方式保存的是dump.rdb文件,恢复也是识别的是dump.rdb
# 配置位置,以及快照恢复
查看目录
CONFIG GET dir获取目录
**将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可 或者就在当前目录启动**
举例:
我的redis启动服务的目录是 /usr/local/bin 下面
我启动redis的目录是/root 下面,然后生成的的dump.rdb 文件也是在/root 目录下,假如redis服务器出现问题,挂掉了。那么想要根据rdb恢复数据
(1)将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务
(2)当前目录启动
如果我的dump.rdb 在/root下面,而我到/usr/local/bin这个目录下去启动了redis,那么数据是无法恢复的。只能从 /root 下面启动才能看到之前保存的数据。
如下操作:
~~~
127.0.0.1:6379> CONFIG GET dir #获取当前操作的目录
1) "dir"
2) "/root"
127.0.0.1:6379> KEYS * #redis中存在的key
1) "myhash"
2) "k3"
3) "mylist"
4) "b1"
5) "du1"
6) "k1"
7) "b4"
8) "key1"
9) "d"
10) "myset"
11) "du11"
12) "list"
13) "b3"
14) "du"
15) "b2"
16) "skey"
17) "k2"
127.0.0.1:6379>
~~~
下面我关闭redis,假设redis服务挂掉!
~~~
127.0.0.1:6379> SHUTDOWN #关闭服务器
[root@localhost ~]# pwd #当前目录是/root
/root
[root@localhost ~]# ll #下面有dump.rdb这个文件
总用量 52
-rw-------. 1 root root 1208 6月 14 08:10 anaconda-ks.cfg
drwxr-xr-x. 3 root root 4096 6月 17 04:35 dufy
-rw-r--r--. 1 root root 283 6月 19 00:13 dump.rdb
-rw-r--r--. 1 root root 24772 6月 14 08:10 install.log
-rw-r--r--. 1 root root 7690 6月 14 08:09 install.log.syslog
~~~
那么当我进入/usr/local/bin 目录下启动重新启动redis,看数据是否恢复
~~~
[root@localhost ~]# cd /usr/local/bin/
[root@localhost bin]# pwd
/usr/local/bin
[root@localhost bin]# redis-server /root/dufy/redis/redis-3.0.4/redis.conf
[root@localhost bin]# redis-cli
127.0.0.1:6379> KEYS * # 这里启动后,查看key没有恢复
(empty list or set)
127.0.0.1:6379>
~~~
那么我再次关闭服务,从/root下启动redis看数据是否恢复
~~~
127.0.0.1:6379> SHUTDOWN
not connected> exit
[root@localhost bin]# cd /root/
[root@localhost ~]# pwd
/root
[root@localhost ~]# redis-server /root/dufy/redis/redis-3.0.4/redis.conf
[root@localhost ~]# redis-cli
127.0.0.1:6379> KEYS * #重启后,查看key,发现恢复成功了!
1) "k1"
2) "b1"
3) "key1"
4) "list"
5) "du11"
6) "du1"
7) "b4"
8) "k3"
9) "myhash"
10) "b3"
11) "d"
12) "skey"
13) "mylist"
14) "du"
15) "k2"
16) "b2"
17) "myset"
127.0.0.1:6379>
~~~
相信我这些操作,也讲明白快照恢复,上面说的这一句:将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可或者就在当前目录启动。
# Redis优点
适合大规模的数据恢复
对数据完整性和一致性要求不高
# Redis缺点
在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改
fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑
# 如何停止RDB
## 配置文件注释掉
~~~
save 900 1
save 300 10
save 60 10000
~~~
启动 # save “”, 去掉 #。保存后重启
## 动态停止RDB命令
在redis-cli中执行:
~~~
config set save ""
~~~
# 大总结
内存中的数据对象 --->rdbsave --> 磁盘中的rdb文件
内存中的数据对象 <---rdload <-- 磁盘中的rdb文件
* RDB是一个非常紧凑的文件
* RDB在保存RDB文件时父进程唯一需要做的就是foker出一个子进程,接下来工作全部交给子进程来做,父进程不需要再做其他IO操作,所以RDB持久化方式可以最大化redis的性能
* 与AOF相比,在恢复大的数据时候,RDB方式更快一些
* 数据丢失风险大
* RDB需要经常folk子进程来保存数据集到磁盘,当数据集比较大额时候,folk的过程是比较耗时的,可能会导致redis在一些毫秒级不能响应客服端请
- SQL
- 名词
- mysql
- 初识mysql
- 备份和恢复
- 存储引擎
- 数据表损坏和修复
- mysql工具
- 数据库操作
- 增
- 删
- 改
- 查
- 数据类型
- 整数类型
- 小数类型
- 日期时间类型
- 字符和文本型
- enum类型
- set类型
- 时间类型
- null与not null和null与空值''的区别
- 数据表操作
- 创建
- 索引
- 约束
- 表选项列表
- 表的其他语句
- 视图
- sql增删改查
- sql增
- sql删
- sql改
- sql查
- sql语句练习
- 连接查询和更新
- 常用sql语句集锦
- 函数
- 字符函数
- 数值运算符
- 比较运算符与函数
- 日期时间函数
- 信息函数
- 聚合函数
- 加密函数
- null函数
- 用户权限管理
- 用户管理
- 权限管理
- pdo
- 与pdo相关的几个类
- 连接数据库
- 使用
- pdo的错误处理
- pdo结果集对象
- pdo结果集对象常用方法
- pdo预处理
- 常用属性
- mysql编程
- 事务
- 语句块
- mysql中的变量
- 存储函数
- 存储过程
- 触发器
- mysql优化
- 存储引擎
- 字段类型
- 三范式和逆范式
- 索引
- 查询缓存
- limit分页优化
- 分区
- 介绍
- 分区算法
- list分区
- range范围
- Hash哈希
- key键值
- 分区管理
- 特别注意
- 分表
- 数据碎片与维护
- innodb表压缩
- 慢查询
- explain执行计划
- count和max,groupby优化
- 子查询优化
- mysql锁机制
- 介绍
- 演示
- 总结
- 乐观锁和悲观锁
- 扛得住的mysql
- 实例和故事
- 系统参数优化
- mysql体系结构
- mysql基准测试
- 索引
- mysql的复制
- win配置MySQL主从
- mysql5.7新特性
- 常见问题
- general log
- 忘记密码
- uodo log与redo log
- 事务隔离级别
- mysql8密码登录
- explain
- 高效的Tree表
- on delete cascade 总结
- mongod
- 简介
- 集合文档操作语句
- 增删改查
- 索引
- 数据导入和导出
- 主从复制
- php7操作mongod
- 权限管理
- redis
- redis简介
- 3.2版本配置文件
- 3.0版本配置文件
- 2.8版本配置文件
- 配置文件总结
- 外网连接
- 持久化
- RDB备份方式保存数据
- AOF备份方式保存数据
- 总结
- win安装redis和sentinel部署
- 事务
- Sentinel模式配置
- 分布式锁
- 管道
- php中redis代码
- 发布订阅
- slowlog
- Redis4.0
- scan和keys
- elasticsearch
- 配置说明
- 启动
- kibana
- kibana下载
- kibana配置文件
- kibana常用功能
- 常用术语
- Beats
- Beats简介
- Filebeat
- Packetbeat
- Logstash
- 配置
- elasticsearch架构
- es1.7
- head和bigdesk插件
- 插件大全
- 倒排索引
- 单模式下API增删改查
- mget获取多个文档
- 批量操作bulk
- 版本控制
- Mapping映射
- 基本查询
- Filter过滤
- 组合查询
- es配置文件
- es集群优化和管理
- logstash
- kibana
- es5.2
- 安装
- 冲突处理
- 数据备份
- 缺陷不足
- 集群管理api
- 分布式事务
- CAP理论
- BASE模型
- 两阶段提交(2PC)
- TCC (Try-Confirm-Cancle)
- 异步确保型
- 最大努力通知型
- 总结