Redis持久化RDB,AOF

目   录

CONFIG动态修改配置

慢查询

持久化

---

在上一篇主要对redis的了解入门，安装，以及基础配置，多实例的实现：redis的安装看我上一篇：

Redis安装部署与使用,多实例

redis是挡在MySQL前面的，运行在内存中的，速度就快，单线程的。

redis的一些基础配置：

在上一篇redis介绍中，介绍了bind配置，使得远端主机能够登录本机redis。密码requirepass的设置，以及多实例基于端口号port的配置，pid文件pidfile，日志文件logfile，工作目录dbfilename配置。

bind 0.0.0.0 #监听地址，可以用空格隔开后多个监听IP

port 6379 #监听端口,默认6379/tcp

tcp-keepalive 300 #tcp 会话保持时间300s

daemonize no #默认no,即直接运行redis-server程序时,不作为守护进程运行，而是以前台方式运行，如果想在后台运行需改成yes,当redis作为守护进程运行的时候，它会写一个 pid 到/var/run/redis.pid 文件

pidfile /var/run/redis_6379.pid #pid文件路径,可以修改为/apps/redis/run/redis_6379.pid

loglevel notice #日志级别
logfile "/path/redis.log" #日志路径,示例:logfile "/apps/redis/log/redis_6379.log"databases 16 #设置数据库数量，默认：0-15，共16个库

save 900 1 #在900秒内有1个key内容发生更改,就执行快照机制
save 300 10 #在300秒内有10个key内容发生更改,就执行快照机制
save 60  10000  #60秒内如果有10000个key以上的变化，就自动快照备份

rdbcompression yes #持久化到RDB文件时，是否压缩，"yes"为压缩，"no"则反之

dbfilename dump.rdb #快照文件名

dir ./ #快照文件保存路径，示例：dir "/apps/redis/data"

maxclients 10000 #Redis最大连接客户端

appendfilename "appendonly.aof" #文本文件AOF的文件名，存放在dir指令指定的目录中

appendfsync everysec

#aof持久化策略的配置
#no表示由操作系统保证数据同步到磁盘,Linux的默认fsync策略是30秒，最多会丢失30s的数据
#always表示每次写入都执行fsync，以保证数据同步到磁盘,安全性高,性能较差
#everysec表示每秒执行一次fsync，可能会导致丢失这1s数据,此为默认值,也生产建议值

auto-aof-rewrite-min-size 64mb #触发aof rewrite的最小文件大小

cluster-enabled yes #是否开启集群模式，默认不开启,即单机模式

CONFIG动态修改配置

config命令用于查看当前redis配置、以及不重启redis服务实现动态更改redis配置等

注意：不是所有配置都可以动态修改，且此方式无法持久保存

CONFIG SET <parameter> <value>

config set 参数 值

config set 参数值。时间复杂度是O(1)。CONFIG SET 命令可以动态调整redis服务器的配置(confuiguration)而无须重启。

也可以使用它修改配置参数，或者改变redis的持久化（persistence）方式

CONFIG SET 可以修改的配置命令可以使用命令CONFIG GET * 来列出来，所有被CONFIG SET 修改的配置参数都会立即生效。

CONFIG GET 命令用于取得运行中的redis服务器的配置参数(configuration parameters)，在redis2.4版本中，有部分参数没有办法用config get访问，但是在最新的Redis2.6版本中，所有配置参数都已经可以用config get访问了。

config get 接受单个参数parameter作为搜索关键字，查找到所有匹配的配置参数，其中参数和值以键值对的方式排列。

比如执行config get s* 命令，服务器会返回所有以s开头的配置参数及参数值的。

案例：

登录redis：

[root@Node1 ~]#:redis-cli

 使用动态方式查看日志文件路径：

查看以lo开头的配置项：

显示出了有日志文件路径，和日志级别。

相当于：Python中以字典的形式存储

{logfile:"/apps/redis/log/redis.log",loglevel:"notice"}

config设置密码：

127.0.0.1:6379> config set requirepass 12321
OK

 可以看到，必须使用密码登录，-a选项

设置空密码：

慢查询

执行命令，有发送命令，排队等待命令的执行，执行命令，返回结果。

慢查询发生在第3阶段，客户端超时不一定慢查询，但是慢查询时客户端超时的一个可能因素。

范例：slowlog。修改两条配置：

slowlog-log-slower-than 1    #指定为超过1us即为慢的指令
slowlog-max-len 1024         #指定保存1024条慢记录

 指定为超过1微妙即为慢的指令

指定保存1024条慢记录

 查看慢查询具体情况，看前两条

发现记录了我们输入命令查询的语句。

如果get后面不加数字，就是查看全部：

数据库：切换使用select 0,select 1。。。 当前默认是0，

进入数据库使用select 1
在当前设置键值：

切换到数据库1：

获取不到在0上的name。再切换回去就有了

在1上也设置一个name：

使用flushdb命令可以清空当前的数据库

flushall清空所有的数据库

这里清空之后我们再重新设置一个name，叫python。去0上查看name为linux。执行flushall命令清空所有，再回来1上，查看name=python是否被清空。

flushdb清空当前数据库，flushall清空所有数据库。

持久化

redis虽然是一个内存级别的缓存程序，也就是redis是使用内存进行数据的缓存的，但是其可以将内存的数据按照一定的策略保存到硬盘上，从而实现数据持久保存的目的，目前支持redis支持两种不同的方式的数据持久化保存机制，分别是RDB和AOF。

持久化的功能：redis是内存数据库，所有数据都是保存在内存中，为了避免服务器断点等原因导致redis进程异常退出后数据永久丢失，需要定期将redis中的数据以某种形式(数据或者命令)从内存中保存到硬盘上，当下次redis重启时，利用持久化文件实现数据恢复，除此之外为了进行灾难备份，可以持久化将文件拷贝到一个远程位置(如备份服务器)。

redis提供两种方式进行持久化：

RDB持久化：原理是将redis在内存中的数据库记录，定时保存到磁盘上，类似于快照。

AOF持久化：原理是将redis的操作日志以追加的方式写入文件，类似于mysql的binlog

由于AOF持久性实时性更好，即发生特殊情况导致数据丢失时，丢失的数据更少，因此是目前主流的持久化方式，不过RDB持久化仍然具有可用性。

保存持久化：

当一个键设置了多个值，那么get获取键时对应的值就是最近一次的修改。

127.0.0.1:6379> set name linux
OK
127.0.0.1:6379> set name linux1
OK
127.0.0.1:6379> set name linux2
OK
127.0.0.1:6379> get name
"linux2"
127.0.0.1:6379>

那么前面设置的两个值就会残留。占用空间。使用save可以保存持久化。还有一个是bgsave，它不会影响操作，后台执行，不影响操作。重写机制会把最近的记录下载，也就是记录linux3。

建议使用bgsave

持久化中：

dir ./ #快照文件保存路径，示例：dir "/apps/redis/data"。如果不指定，在登录redis时，save会出现错误

dbfilename dump.rdb #快照文件名
appendfilename "appendonly.aof" 和rdb文件共用dir aof保存文件的名字

两个保存文件共用dir中指定的目录

AOF默认是关闭的，在配置文件中开启appendonly

RDB模式：基于时间快照，其默认只保留当前最新的一次快照，特点是执行速度比较快，缺点是可能会丢失从上次快照到当前时间点之间未做快照的数据。

RDB bgsave实现快照的具体过程：

Redis从master主进程先fork出一个子进程，使用写时复制机制，子进程将内存的数据保存为一个临时文件，比如:tmp-.rdb，当数据保存完成之后再将上一次保存的RDB文件替换掉，然后关闭子进程，这样可以保证每一次做RDB快照保存的数据都是完整的因为直接替换RDB文件的时候,可能会出现突然断电等问题,而导致RDB文件还没有保存完整就因为突然关机停止保存,而导致数据丢失的情况.后续可以手动将每次生成的RDB文件进行备份，这样可以最大化保存历史数据

RDB持久化触发条件分为手动触发和自动触发两种：

手动触发：save命令和bgsave命令都可以生成RDB文件。

save命令会阻塞redis服务器进程，直到RDB文件创建完毕为止，在redis服务器阻塞期间，服务器不能处理任何命令请求。

而bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程(即redis主进程)则继续处理请求。

bgsave命令执行过程中，只有fork子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用。往往生产环境bgsave依然不允许轻易使用。

自动触发：

在自动触发RDB持久化时，redis也会选择bgsave而不是save来进行持久化。

save m n

自动触发最常见的情况是在配置文件中通过save m n，指定当m秒内发生n次变化时，会触发bgsave。

自动触发：两个条件都要满足在60秒内，触发两次数据变化才会启动保存。

相关配置：

save 900 1         #900s内修改了1个key即触发保存RDB
save 300 10        #300s内修改了10个key即触发保存RDB
save 60 10000      #60s内修改了10000个key即触发保存RDB

dbfilename dump.rdb
dir ./         #编泽编译安装,默认RDB文件存放在启动redis的工作目录,建议明确指定存入目录stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes

备份操作，执行save的时候注意配置文件，dir指定为/apps/redis/data/下。

可以同时执行保存命令和查看进程，可以看到如图所示；

自动触发：

修改配置文件
#save 900 1
#save 300 10
#save 60 10000
save 60 2

bgsave 在后台备份的时候不知道什么时候完成

[root@Node1 redis]#:redis-cli bgsave ;redis-cli info Persistence |grep rdb_bgsave_in_progress
Background saving started
rdb_bgsave_in_progress:1
[root@Node1 redis]#:
[root@Node1 redis]#:redis-cli info Persistence |grep rdb_bgsave_in_progress
rdb_bgsave_in_progress:0

RDB的优缺点：

优点：

1.RDB快照保存了某个时间点的数据，可以通过脚本执行redis指令bgsave(非阻塞，后台执行)或者save(会阻塞写操作,不推荐)命令自定义时间点备份，可以保留多个备份，当出现问题可以恢复到不同时间点的版本,很适合备份,并且此文件格式也支持有不少第三方工具可以进行后续的数据分析比如: 可以在最近的24小时内，每小时备份一次RDB文件，并且在每个月的每一天，也备份一个RDB文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

缺点：

2.RDB可以最大化Redis的性能，父进程在保存 RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

3.RDB在大量数据,比如几个G的数据，恢复的速度比AOF的快

1.不能实时保存数据，可能会丢失自上一次执行RDB备份到当前的内存数据如果你需要尽量避免在服务器故障时丢失数据，那么RDB并不适合。虽然Redis允许设置不同的保存点（save point）来控制保存RDB文件的频率，但是，因为RDB文件需要保存整个数据集的状态，所以它并不是一个轻松快速的操作。因此一般会超过5分钟以上才保存一次RDB文件。在这种情况下，一旦发生故障停机，你就可能会丢失好几分钟的数据。

2.当数据量非常大的时候，从父进程fork子进程进行保存至RDB文件时需要一点时间，可能是毫秒或者秒，取决于磁盘IO性能在数据集比较庞大时，fork()可能会非常耗时，造成服务器在一定时间内停止处理客户端﹔如果数据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒或更久。虽然 AOF重写也需要进行fork()，但无论AOF重写的执行间隔有多长，数据的持久性都不会有任何损失。

AOF模式：

AOF：按照操作顺序依次将操作追加到指定的日志文件末尾。

AOF和RDB一样使用了写时复制机制，AOF默认为每秒钟fsync一次，即将执行的命令保存到AOF文件当中，这样即使redis服务器发生故障最多只丢失1秒中之内的数据，也可以设置不同的fsync策略always，即设置每次执行命令的时候执行fsync，fsync会在后台执行线程，所以主线程可以继续处理用户的正常请求而不受到写入AOF文件的影响。

同时启用RDB和AOF，进行恢复时，默认AOF文件优先级高于RDB文件，即会使用AOF文件进行恢复。

注意：AOF模式默认是关闭的，第一次开启AOF后，并重启服务生效后，会因为AOF的优先级高于RDB，而先恢复AOF文件

AOF默认没有数据文件存在，从而导致所有数据丢失。

是否开启AOF

appendonly no #是否开启AOF日志记录，默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了，但是redis如果中途宕机，会导致可能有几分钟的数据丢失(取决于dump数据的间隔时间)，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性，Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。默认不启用此功能

开启后重启，默认是与RDB在一个路径下：

数据发生修改后，会自动记录：

保存规则：

everysec表示每秒执行一次fsync，可能会导致丢失这1s数据，此为默认值，也生产建议值。

重写规则，rewrite相关。

no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100 
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes

当如果同时开启了AOF和RDB是如何正确恢复：

AOF优先级比RDB要高。

同时开启只会同步AOF文件。

AOF重写机制

将一些重复的,可以合并的,过期的数据重新写入一个新的AOF文件,从而节约AOF备份占用的硬盘空间,也能加速恢复过程

可以手动执行 bgrewriteaof 触发AOF,第一次开启AOF功能,或定义自动 rewrite 策略

---end---