美文网首页
66.8-Redis持久化方案

66.8-Redis持久化方案

作者: BeautifulSoulpy | 来源:发表于2020-09-11 21:19 被阅读0次

    成功者不是从不失败,而是从不放弃!


    总结:

    1. Redis持久化方式:RDB(Redis DB)定时保存、AOF(AppendOnlyFile)重演;
    2. 分布式文件系统:将文件分散在不同的节点上,不同节点上有多个副本;防止一部分坏了仍然可以使用;

    1. Redis持久化

    持久化:将数据从掉电易失的内存存放到能够永久存储的设备上

    Redis服务是使用内存来存储数据,如果掉电、服务崩溃都会导致Redis中数据丢失,如有必要,可以持久化数据。

    Redis持久化方式:RDB(Redis DB)、AOF(AppendOnlyFile)

    1. RDB

    在默认情况下,Redis 将某时间点的数据库快照保存在名字为 dump.rdb的二进制文件中

    策略
    自动:按照配置文件中的条件满足就执行BGSAVE(后台自动保存)
    手动:客户端发起SAVE、BGSAVE命令

    配置
    save 900 1 
    save 300 10 
    save 60 10000 
    dbfilename dump.rdb 
    dir /var/lib/redis/6379 
    

    save 60 1000,Redis要满足在60秒内至少有1000个键被改动,会自动保存一次
    只要满足上面3个条件之一,就自动执行快照
    执行完后,时间计数器和次数计数器都会归零重新计数。这多个条件不是叠加效果

    SAVE命令:阻塞式命令,执行期间不响应客户端的请求
    BGSAVE:非阻塞命令,执行期间还可以接收并处理客户端请求,会folk一个子进程创建RDB文件

    192.168.142.135:6379> SAVE
    192.168.142.135:6379> BGSAVE
    
    

    优点

    • 完全备份,不同时间的数据集备份可以做到多版本恢复
    • 紧凑的单一文件,方便网络传输,适合灾难恢复
    • 快照文件直接恢复,大数据集速度较AOF快

    缺点
    会丢失最近写入、修改的而未能持久化的数据
    folk过程非常耗时(消耗 内存),会造成毫秒级不能响应客户端请求

    RDB备份策略
    创建一个定时任务cron job,每小时或者每天将dump.rdb复制到指定目录
    确保备份文件名称带有日期时间信息,便于管理和还原对应的时间点的快照版本
    定时任务删除过期的备份
    如果有必要,跨物理主机、跨机架、异地备份

    2. AOF

    Append only file,采用追加的方式保存,默认文件appendonly.aof 。
    记录所有的写操作命令,在服务启动的时候使用这些命令就可以还原数据库(重演)

    AOF写入机制

    AOF方式不能保证绝对不丢失数据
    目前常见的操作系统中,执行系统调用write函数,将一些内容写入到某个文件里面时,为了提高效率,系统通常不会直接将内容写入硬盘里面,而是先将内容放入一个内存缓冲区(buffer)里面,等到缓冲区被填满,或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里,未写入磁盘之前,数据可能会丢失

    写入磁盘的策略
    appendfsync选项,这个选项的值可以是always、everysec或者no

    Always:服务器每写入一个命令,就调用一次fdatasync,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,也不会丢失任何已经成功执行的命令数据
    Everysec(默认):服务器每一秒重调用一次fdatasync,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,最多只丢失一秒钟内的执行的命令数据
    No:服务器不主动调用fdatasync,由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下,服务器遭遇意外停机时,丢失命令的数量是不确定的

    运行速度:always的速度慢,everysec和no都很快

    AOF重写机制

    写操作越来越多的被记录,AOF文件会很大。Redis会合并写操作,以压缩AOF文件。
    合并重复的写操作,AOF会使用尽可能少的命令来记录。

    重写过程

    1. folk一个子进程负责重写AOF文件
    2. 子进程会创建一个临时文件写入AOF信息
    3. 父进程会开辟一个内存缓冲区接收新的写命令
    4. 子进程重写完成后,父进程会获得一个信号,将父进程接收到的新的写操作由子进程写入到临时文件中
    5. 新文件替代旧文件

    注:如果写入操作的时候出现故障导致命令写半截,可以使用redis-check-aof工具修复

    原有AOF文件 重写后的AOF文件
    SELECT 0 SELECT 0
    SADD fruits “apple” SADD fruits “apple” “banana” “cherry”
    SADD fruits “banana” SET msg “hello world again!”
    SADD fruits “cherry” RPUSH lst 3 5 7
    SADD fruits “apple”
    INCR counter
    INCR counter
    DEL counter
    SET msg “hello world”
    SET msg “hello world again!”
    RPUSH lst 1 3 5
    RPUSH lst 7
    LPOP lst
    AOF重写触发

    手动:客户端向服务器发送BGREWRITEAOF命令
    自动:配置文件中的选项,自动执行BGREWRITEAOF命令

    auto-aof-rewrite-min-size <size> ,触发AOF重写所需的最小体积:只要在AOF文件的体积大于等于size时,才会考虑是否需要进行AOF重写,这个选项用于避免对体积过小的AOF文件进行重写

    auto-aof-rewrite-percentage <percent> ,指定触发重写所需的AOF文件体积百分比:当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积,并且超过上一次重写之后的AOF文件体积的percent %时,就会触发AOF重写。(如果服务器刚刚启动不久,还没有进行过AOF重写,那么使用服务器启动时载入的AOF文件的体积来作为基准值)。将这个值设置为0表示关闭自动AOF重写

    重写配置举例

    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb
    当AOF文件大于64MB时候,可以考虑重写AOF文件
    只有当AOF文件的增量大于起始size的100%时(就是文件大小翻了一倍),启动重写
    
    appendonly yes
    默认关闭,请开启
    

    优点
    写入机制,默认fysnc每秒执行,性能很好不阻塞服务,最多丢失一秒的数据
    重写机制,可以优化AOF文件体积
    如果误操作了(FLUSHALL等),只要AOF未被重写,停止服务移除AOF文件尾部FLUSHALL命令,重启Redis,可以将数据集恢复到FLUSHALL 执行之前的状态

    缺点
    相同数据集,AOF文件(文本)体积较RDB大了很多
    恢复数据库速度叫RDB慢(文本,命令重演)

    相关文章

      网友评论

          本文标题:66.8-Redis持久化方案

          本文链接:https://www.haomeiwen.com/subject/odibektx.html