• 9.快照持久化和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持久化可以一起来还原。
    还原的时候也十分简单,在任何一台服务器上,只要拿到备份文件,都可以进行数据备份。

    至此,两种持久化方式介绍完毕。

    转载请注明出处:http://blog.csdn.net/acmman/article/details/53421960

  • 相关阅读:
    (重要)1
    大数据技术
    条件随机场之CRF++源码详解-预测
    条件随机场之CRF++源码详解-训练
    条件随机场之CRF++源码详解-特征
    条件随机场之CRF++源码详解-开篇
    这个更新需要花去 50.6 M 磁盘上总计 /boot 的空间。请在 7737k 磁盘上留出 /boot 空间。清空您的回收站和临时文件,用“sudo apt-get clean
    多线程:pthread_exit,pthread_join,pthread_self
    error: ‘for’ loop initial declarations are only allowed in
    多线程
  • 原文地址:https://www.cnblogs.com/kdy11/p/8892857.html
Copyright © 2020-2023  润新知