Redis 持久化配置

前言

Redis为持久化提供了两种方式：

RDB：在指定的时间间隔能对你的数据进行快照存储。
AOF：记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据。

性能	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据策略决定
轻重	重	轻

一、RDB的持久化

在Redis中RDB持久化的触发分为两种：自己手动触发与Redis定时触发

`手动触发`

save：会阻塞当前Redis服务器，直到持久化完成，线上应该禁止使用。
bgsave：该触发方式会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候。

`自动触发`

根据我们的 save m n 配置规则自动触发；
从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发 bgsave；
执行 debug reload 时；
执行 shutdown （退出）时，如果没有开启aof，也会触发。

1、RDB策略配置文件

# 时间策略
save 900 1
save 300 10
save 60 10000# 文件名称
dbfilename dump.rdb# 文件保存路径
dir /home/work/app/redis/data/# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes# 是否压缩
rdbcompression yes# 导入时是否检查
rdbchecksum yes

`时间策略`

save 900 1 表示900s内如果有1条是写入命令，就触发产生一次快照，可以理解为就进行一次备份
save 300 10 表示300s内有10条写入，就产生快照
save 60 10000 表示60秒内有10000条写入，就产生快照

stop-writes-on-bgsave-error yes这个配置也是非常重要的一项配置，这是当备份进程出错时，主进程就停止接受新的写入操作，是为了保护持久化的数据一致性问题。如果自己的业务有完善的监控系统，可以禁止此项配置，否则请开启。

关于压缩的配置 rdbcompression yes，建议没有必要开启，毕竟Redis本身就属于CPU密集型服务器，再开启压缩会带来更多的CPU消耗，相比硬盘成本，CPU更值钱。

RDM持久策略关闭方法：
方法1：redis命令窗口里输入命令 config set save ""即可
方法2：修改配置文件，注释掉三个save，并打开save "" 的注释，使得 save "" 生效，即可关闭rdb；

save ""#save 900 1
#save 300 10
#save 60 10000

2、RDM持久化测试

在 redis-cli 端创建 key 键值

127.0.0.1:6379> set RDB:test1 mykey1
OK
127.0.0.1:6379> set RDB:test2 mykey2
OK
127.0.0.1:6379> set RDB:test3 mykey3
OK
127.0.0.1:6379> set RDB:test4 mykey4
127.0.0.1:6379> keys *
1) "RDB:test4"
2) "RDB:test3"
3) "RDB:test2"
4) "RDB:test1"

退出redis-cli端，查看dump.rdm文件（查看dump.rdm文件需要安装redis-rdb-tools工具）
重启redis服务，查看数据是否持久化

127.0.0.1:6379> keys *
1) "RDB:test4"
2) "RDB:test3"
3) "RDB:test2"
4) "RDB:test1"

PS：若将dump.rdm文件删除，则数据丢失；

二、AOF的持久化

AOF的整个流程大体来看可以分为两步

第一步是命令的实时写入（如果是 appendfsync everysec 配置，会有1s损耗）；
第二步是对aof文件的重写；

对于增量追加到文件这一步主要的流程是：命令写入 =》 追加到aof_buf =》同步到aof磁盘

那么这里为什么要先写入buf 再同步到磁盘呢？如果实时写入磁盘会带来非常高的磁盘IO，影响整体性能。

aof重写是为了减少aof文件的大小，可以手动或者自动触发，关于自动触发的规则请看上面配置部分。fork的操作也是发生在重写这一步，也是这里会对主进程产生阻塞。

手动触发： bgrewriteaof，自动触发 就是根据配置规则来触发，当然自动触发的整体时间还跟Redis的定时任务频率有关系。

对于上图有四个关键点补充一下：

在重写期间，由于主进程依然在响应命令，为了保证最终备份的完整性，它依然会写入到旧的AOF file中，如果重写失败，能够保证数据不丢失。
为了把重写期间响应的写入信息也写入到新的文件中，因此也会为子进程保留一个buf，防止新写的file丢失数据。
重写是直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析、命令合并。
AOF文件直接采用的文本协议，主要是兼容性好、追加方便、可读性高可随时可修改修复。

1、AOF策略配置文件

# 是否开启aof
appendonly yes# 文件名称，文件保存在启动目录下
appendfilename "appendonly.aof"# 同步方式
appendfsync everysec# aof重写期间是否同步
no-appendfsync-on-rewrite no# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb# 加载aof时如果有错如何处理
aof-load-truncated yes# 文件重写策略
aof-rewrite-incremental-fsync yes

`appendfsync everysec` 它其实有三种模式:

always：把每个写命令都立即同步到aof，很慢，但是很安全
everysec：每秒同步一次，是折中方案
no：redis不处理交给OS来处理，非常快，但是也最不安全

一般情况下都采用 everysec 配置，这样可以兼顾速度与安全，最多损失1s的数据。

`aof-load-truncated yes`

如果该配置启用，在加载时发现aof尾部不正确时，会向客户端写入一个log，但是会继续执行
如果设置为 no ，发现错误就会停止，必须修复后才能重新加载

2、AOF持久化测试

PS：在测试之前，为数据准确性，需要关闭RDB持久化策略

启动redis进程，并进入redis

[root@localhost bin]# redis-server redis.conf
[root@localhost bin]# redis-cli

创建测试key键值，并将所有 key 键值清除（为下面恢复数据做准备）

127.0.0.1:6379> set name villian          ///创建3个测试键值
OK
127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> set home shenzhen
OK
127.0.0.1:6379> flushdb                      ///清空库中的键值，为下面做测试准备
127.0.0.1:6379> shutdown                     ///退出redis

退出后，在启动目录下自动生成 appendonly.aof 文件

[root@localhost bin]# ls
appendonly.aof

进入到该文件查看数据，并删除flushdb命令，测试恢复数据

[root@localhost bin]# vim appendonly.aof
*3
$3
set
$4
name
$3
zwl
*3
$3
set
$3
age
$2
20
*3
$3
set
$4
home
$8
shenzhen
*1
$7
flushdb                     ///此命令为上述清空命令，将此命令删除，并保存退出

数据恢复（将上面最后一个flushdb命令删除，再重新启动redis-server服务即可）

127.0.0.1:6379> keys *
1) "home"
2) "name"
3) "age"

AOF持久策略关闭方法：
方法1：redis命令窗口里输入命令 config set appendfsync no即可
方法2：修改配置文件，将appendonly设置为no，默认是 appendonly no，即可关闭aof；

三、从持久化中恢复数据

恢复数据，只需要重新启动Redis（命令：redis-server redis.conf）即可。

启动时会先检查AOF文件是否存在，如果不存在就尝试加载RDB。那么为什么会优先加载AOF呢？因为AOF保存的数据更完整，通过上面的分析我们知道AOF基本上最多损失1s的数据。

四、性能与实践分析

通过上面的分析，我们都知道RDB的快照、AOF的重写都需要fork，这是一个重量级操作，会对Redis造成阻塞。因此为了不影响Redis主进程响应，我们需要尽可能降低阻塞。

降低fork的频率，比如可以手动来触发RDB生成快照、与AOF重写；
控制Redis最大使用内存，防止fork耗时过长；
使用更牛逼的硬件；
合理配置Linux的内存分配策略，避免因为物理内存不足导致fork失败。

策略：

如果Redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据，可以关闭持久化，如果丢失数据可以通过其它途径补回；
自己制定策略定期检查Redis的情况，然后可以手动触发备份、重写数据；
单机如果部署多个实例，要防止多个机器同时运行持久化、重写操作，防止出现内存、CPU、IO资源竞争，让持久化变为串行；
可以加入主从机器，利用一台从机器进行备份处理，其它机器正常响应客户端的命令；
RDB持久化与AOF持久化可以同时存在，配合使用；

redis的 rdb 和 aof 持久化的区别
一起看懂Redis两种持久化方式的原理

运维之道 | Redis 持久化配置相关推荐

运维之道 | Redis 集群搭建
Redis 集群搭建集群中至少应该有奇数个节点,所以搭建集群最少需要3台主机.同时每个节点至少有一个备份节点,所以下面最少需要创建使用6台主机,才能完成Redis Cluster 集群搭建(主节点. ...
运维之道 | Redis 命令解析大全
Redis 命令解析大全一.Redis keys 命令如果命令执行成功,则命令执行后输出 (integer) 1,否则将输出 (integer) 0 新建key set keyname redis ...
运维之道 | 基于 LAMP 环境部署 Discuz 论坛
基于 LAMP 环境部署 Discuz 论坛 LAMP环境部署一.基于VMware虚拟机部署Centos系统 [root@localhost ~]# cat /etc/redhat-release ...
运维之道 | Mysql主从复制+mycat读写分离
运维之道 | Mysql主从复制 + Mycat读写分离 1.什么是读写分离读写分离,基本的原理是让主数据库处理事务性增.删.改操作(INSERT.UPDATE.DROP),而从数据库处理SELEC ...
运维之道 | Zabbix监控mysql主从同步状态并设置触发微信告警
一.主机规划服务器 IP zabbix-server 192.168.1.111 mysql-master.zabbix-agent 192.168.1.115 mysql-slave.zabbix ...
专访优维科技CTO黎明：探寻当下的IT运维之道
随着互联网信息和云计算技术的发展,企业的服务器系统从集中计算架构全面过度到海量的分布式计算架构,随之而来的海量服务器维护和管理成为企业运维人员的主要挑战,自动化运维已经成为目前企业服务器系统的主要建设 ...
从扁鹊医术看华为数据中心智能化运维之道
根据典记,魏文王曾求教于名医扁鹊:"你们家兄弟三人,都精于医术,谁医术最好呢?"扁鹊:"大哥最好,二哥差些,我是三人中最差的一个."文王又问:"那为什 ...
力作推荐!!!! 防线：企业Linux安全运维理念和实战（向世界500强企业学习Linux安全管理与运维之道）...
防线:企业Linux安全运维理念和实战(向世界500强企业学习Linux安全管理与运维之道) 新书发售 http://product.dangdang.com/product.aspx?pr ...
【大型网站运维之道天道人道运维之道】
大型网站运维之道漫谈网站运维绝不是某些人眼中安装系统.做几根网线那么简单: 除去应用开发和业务运营之外的保障网站能运转的事儿都可能是运维工作的职责范围.本系列是冯大辉(Fenng)的一个系列博文,从 ...

运维之道 | Redis 持久化配置

Redis 持久化配置

前言

一、RDB的持久化

`手动触发`

`自动触发`

1、RDB策略配置文件

`时间策略`

2、RDM持久化测试

二、AOF的持久化

1、AOF策略配置文件

`appendfsync everysec` 它其实有三种模式:

`aof-load-truncated yes`

2、AOF持久化测试

三、从持久化中恢复数据

四、性能与实践分析

运维之道 | Redis 持久化配置相关推荐

最新文章

热门文章

运维之道 | Redis 持久化配置

Redis 持久化配置

前言

一、RDB的持久化

手动触发

自动触发

1、RDB策略配置文件

时间策略

2、RDM持久化测试

二、AOF的持久化

1、AOF策略配置文件

appendfsync everysec 它其实有三种模式:

aof-load-truncated yes

2、AOF持久化测试

三、从持久化中恢复数据

四、性能与实践分析

运维之道 | Redis 持久化配置相关推荐

最新文章

热门文章

`手动触发`

`自动触发`

`时间策略`

`appendfsync everysec` 它其实有三种模式:

`aof-load-truncated yes`