持久化功能
redis为了内部数据的安全考虑,会把本身的数据以文件形式保存到硬盘中一份,在服务器
重启之后会把硬盘中的数据恢复到内存(redis)的里边。
数据保存到硬盘的过程就称为“持久化”效果。
redis有两种持久化功能,一种是“快照持久化”,一种是“AOF持久化”。
1.snap shotting快照持久化
该持久化默认开启,一次性把redis中全部的数据保存一份存储在硬盘中,如果数据非常多
(10-20G)就不合适频繁操作该持久化操作。
我们的快照持久化在硬盘中保留的备份在:
默认的文件名为dump.rdb
在我们的redis安装目录下有一个redis.conf配置文件,其中就有快照持久化的配置:
上图配置的就是快照持久化的“备份频率”。
以上三个save的意思:
数据修改的频率非常高,备份的频率也高
数据修改的频率低,备份的频率也低
以上的配置三个都不能缺少,这样能保证不管修改数据频率高还是低的情况,数据都会保存。
其中快照持久化的文件的名称和存储位置在配置文件中也有配置:
手动发起快照持久化:
我们首先在Redis中加入一些数据:
我们添加了好多testN的数据,为了持久化这些变化,我们手动发起快照持久化:
可以看到,原来备份文件时间未11月12日,现在变为了程序修改的20日了:
我们看一看我们的缓存文件中都保存了什么:
我们之前的改动都有记录在备份文件中。
redis的持久化相关指令:
bgsave 异步保存数据到磁盘(快照保存)
lastsave 返回上次成功保存到磁盘的unix时间戳
shutdown 同步保存到服务器并关闭redis服务器
bgrewriteaof 当日志文件过长时优化AOF日志文件存储
快照持久化缺点:
一下是一次快照的模拟:
每隔一个小时做一次快照持久化
可以看到,我们在10:00-11:00的时候断电了,按照我们每一个小时做的快照持久化来看,
11:00才执行的快照,就无法挽回10:00-10:55分的数据。
解决方案:
每隔一个小时做一次快照持久化
在每一个小时内,我们做“精细持久化”,也就是每修改一个key就保存起来,
并且频率可以达到秒级。不管你1秒内修改了多少key,只做一次持久化,这样
也比较节省内存。
上面所说的“精细持久化”也就是Redis的第二种持久化方法---append only file(AOF持久化)。
2.append only file(AOF持久化)
回想一下,mysql数据库的备份也就是备份了一些sql语句,还原的时候执行sql语句就就行了。
其实AOF持久化就是类似的操作。
AOF持久化本质:把用户执行的每个“写”指令(添加/修改/删除)都备份到文件中,还原数据的时候
就是执行具体写指令而已。
开启AOF持久化(会清空redis内部的数据,最好在redis使用之前就开启它)
我们在redis.conf配置文件中可以找到它:
将“no”改为“yes”,就开启了快照持久化。
我们也可以更改AOP持久化文件名称(文件位置与dump.rdb同一目录)。
配置文件被修改后,要删除旧的进程,再根据新的配置文件启动新进程:
然后就可以在同级目录下,发现一个AOF持久化备份文件appendpnly.aof
然后就发现所有的数据全部清空了(默认)
数据库0-15数据库都是空的。
我们在数据库0中创建了三个key
然后回到根目录看一下备份文件,发现时间和大小都有所改变:
然后查看一下内容:
发现我们写的指令全部都备份进去了,说明备份频率还是十分高的。
在redis.conf中,可以调整AOF备份的频率:
有三种备份方式:
(1) always
一写指令就备份一次。这样做虽然安全,但是系统性能会降低。不推荐使用
(2) everysec
每一秒中备份一次。不管一秒钟变化了多少key,只备份一次,性能得到一定的保护。推荐使用。
(3) no
会查看当前服务器状态,如果状态良好,就进行备份(随机)。这种备份方式数据是没有保证的。
对比下来,性能:always<everysec<no,而数据安全:always>everysec>no。
我们做一个例子,创建一个num数据,使用incr指令对其每过一秒自增一次:
我们查看我们的appendonly.aof文件,看看备份情况:
其实自增10次(10个incr num)就相当于一个set num 10,如果只存储“set num 10”,那么
备份文件的存储空间就会节省了一些。这就牵扯到了我们如何“为aof备份文件做优化处理”。
3.为AOF备份文件做优化处理
所谓优化,其实就是把AOF备份文件中所有的备份数据的内容进行一个处理。
在启动redis客户端的时候,使用bgrewriteaof指令,就可以对aof备份文件的内容进行
优化压缩处理。
我们可以发现aof的大小由字节变为字节,证明其内容被压缩了
看一下其中的内容,发现备份数据存储指令变了:
果然,10次的incr num变成了一次的set num 10
总结:
快照持久化和AOF持久化是一种互补的关系,快照持久化用来做大的备份,
而AOF持久化用来做做精细备份。
数据还原的时候,快照持久化和AOF持久化可以一起来还原。
还原的时候也十分简单,在任何一台服务器上,只要拿到备份文件,都可以进行数据备份。
至此,两种持久化方式介绍完毕。
redis为了内部数据的安全考虑,会把本身的数据以文件形式保存到硬盘中一份,在服务器
重启之后会把硬盘中的数据恢复到内存(redis)的里边。
数据保存到硬盘的过程就称为“持久化”效果。
redis有两种持久化功能,一种是“快照持久化”,一种是“AOF持久化”。
1.snap shotting快照持久化
该持久化默认开启,一次性把redis中全部的数据保存一份存储在硬盘中,如果数据非常多
(10-20G)就不合适频繁操作该持久化操作。
我们的快照持久化在硬盘中保留的备份在:
默认的文件名为dump.rdb
在我们的redis安装目录下有一个redis.conf配置文件,其中就有快照持久化的配置:
上图配置的就是快照持久化的“备份频率”。
以上三个save的意思:
数据修改的频率非常高,备份的频率也高
数据修改的频率低,备份的频率也低
以上的配置三个都不能缺少,这样能保证不管修改数据频率高还是低的情况,数据都会保存。
其中快照持久化的文件的名称和存储位置在配置文件中也有配置:
手动发起快照持久化:
我们首先在Redis中加入一些数据:
我们添加了好多testN的数据,为了持久化这些变化,我们手动发起快照持久化:
可以看到,原来备份文件时间未11月12日,现在变为了程序修改的20日了:
我们看一看我们的缓存文件中都保存了什么:
我们之前的改动都有记录在备份文件中。
redis的持久化相关指令:
bgsave 异步保存数据到磁盘(快照保存)
lastsave 返回上次成功保存到磁盘的unix时间戳
shutdown 同步保存到服务器并关闭redis服务器
bgrewriteaof 当日志文件过长时优化AOF日志文件存储
快照持久化缺点:
一下是一次快照的模拟:
每隔一个小时做一次快照持久化
可以看到,我们在10:00-11:00的时候断电了,按照我们每一个小时做的快照持久化来看,
11:00才执行的快照,就无法挽回10:00-10:55分的数据。
解决方案:
每隔一个小时做一次快照持久化
在每一个小时内,我们做“精细持久化”,也就是每修改一个key就保存起来,
并且频率可以达到秒级。不管你1秒内修改了多少key,只做一次持久化,这样
也比较节省内存。
上面所说的“精细持久化”也就是Redis的第二种持久化方法---append only file(AOF持久化)。
2.append only file(AOF持久化)
回想一下,mysql数据库的备份也就是备份了一些sql语句,还原的时候执行sql语句就就行了。
其实AOF持久化就是类似的操作。
AOF持久化本质:把用户执行的每个“写”指令(添加/修改/删除)都备份到文件中,还原数据的时候
就是执行具体写指令而已。
开启AOF持久化(会清空redis内部的数据,最好在redis使用之前就开启它)
我们在redis.conf配置文件中可以找到它:
将“no”改为“yes”,就开启了快照持久化。
我们也可以更改AOP持久化文件名称(文件位置与dump.rdb同一目录)。
配置文件被修改后,要删除旧的进程,再根据新的配置文件启动新进程:
然后就可以在同级目录下,发现一个AOF持久化备份文件appendpnly.aof
然后就发现所有的数据全部清空了(默认)
数据库0-15数据库都是空的。
我们在数据库0中创建了三个key
然后回到根目录看一下备份文件,发现时间和大小都有所改变:
然后查看一下内容:
发现我们写的指令全部都备份进去了,说明备份频率还是十分高的。
在redis.conf中,可以调整AOF备份的频率:
有三种备份方式:
(1) always
一写指令就备份一次。这样做虽然安全,但是系统性能会降低。不推荐使用
(2) everysec
每一秒中备份一次。不管一秒钟变化了多少key,只备份一次,性能得到一定的保护。推荐使用。
(3) no
会查看当前服务器状态,如果状态良好,就进行备份(随机)。这种备份方式数据是没有保证的。
对比下来,性能:always<everysec<no,而数据安全:always>everysec>no。
我们做一个例子,创建一个num数据,使用incr指令对其每过一秒自增一次:
我们查看我们的appendonly.aof文件,看看备份情况:
其实自增10次(10个incr num)就相当于一个set num 10,如果只存储“set num 10”,那么
备份文件的存储空间就会节省了一些。这就牵扯到了我们如何“为aof备份文件做优化处理”。
3.为AOF备份文件做优化处理
所谓优化,其实就是把AOF备份文件中所有的备份数据的内容进行一个处理。
在启动redis客户端的时候,使用bgrewriteaof指令,就可以对aof备份文件的内容进行
优化压缩处理。
我们可以发现aof的大小由字节变为字节,证明其内容被压缩了
看一下其中的内容,发现备份数据存储指令变了:
果然,10次的incr num变成了一次的set num 10
总结:
快照持久化和AOF持久化是一种互补的关系,快照持久化用来做大的备份,
而AOF持久化用来做做精细备份。
数据还原的时候,快照持久化和AOF持久化可以一起来还原。
还原的时候也十分简单,在任何一台服务器上,只要拿到备份文件,都可以进行数据备份。
至此,两种持久化方式介绍完毕。