5.Redis的持久化

Redis中数据的持久化有两种方式;RDB(Redis DataBsse) 和 AOF(Append Only File),默认采取的是RDB方式

RDB

  1.是什么:在指定的时间间隔内将内存中的数据集快照写入磁盘,

  也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里

  Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,

  待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。

  整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。

  RDB的缺点是最后一次持久化后的数据可能丢失。

  2.Fork

    fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程

  3.RDB保存的是dump.rdb文件

  4.配置位置(在前面有提到配置文件中 SNAPSHOTING快照的相关配置)

  5.如何触发RDB快照(Redis的启动默认不会创建RDB文件)

    a)配置文件中默认的快照配置  冷拷贝后重新使用  cp  dump.rdb  dump_new.rdb

    b)save命令 或者是 bgsave:

      save:save时只管保存,其他不管,其他全部阻塞

      bgsave:Redis会在后台进行快照操作,快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间

    c)执行flushall命令也会产生dump.rdb文件,但里面是空的,无意义

    d)Redis的关闭  : shutdown命令执行,本质上相当于执行了commit,会把那些已经执行了,但是还有没有存到dump.rdb中的数据,commit到RDB中    类似于执行了一个save

  

  6.如何恢复  将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可  CONFIG GET dir获取目录

  7.优势:适合大规模的数据恢复    对数据完整性和一致性要求不高时使用

  

  8.劣势:在一定时间间隔做一次备份,所以如何Redis意外 down 掉的话,就会丢失最后一次快照后的所有修改

      fork的时候,内存中的数据被克隆了一份,大致两倍的膨胀性需要考虑

  

  9.如何停止;动态停止RDB所有保存规则的方法   redis-cli  config  set  save ""

AOF

  a)是什么

  以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

  AOF保存的是 appendonly.aof文件(按照策略进行保存)(默认每秒保存一次)

  b)AOF启动/修复/恢复

    AOF启动:修改默认的 appendonly  no ,改为yes

    正常恢复

      将有数据的aof文件复制一份保存到对应目录(config get dir)

      恢复:重启redis然后重新加载

    异常恢复

      备份被写坏的AOF文件

      修复:redis-check-aof   --fix

      恢复:重启redis然后重新加载

  

  c)rewrite(重写来完成文件压缩)

    AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

    AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进程的内存中数据,每条记录有一条的Set语句。重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似

    触发机制:Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

  

  d)使用AOF方式持久化的优势,采用的三种策略

    1.每修改同步:appendfsync always   同步持久化 每次发生数据变更会被立即记录到磁盘  性能较差但数据完整性比较好

    2.每秒同步:appendfsync everysec    异步操作,每秒记录   如果一秒内宕机,有数据丢失

    3.不同步:不同步:appendfsync no   从不同步,依赖系统记录(30秒)

  e)劣势:

    相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb

    aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同

两种持久化方式总结:

  1.RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储

  2.AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候或重新执行一遍这些命令来恢复原始的数据

   AOF命令以redis协议追加保存每次写的操作 到文件末尾

   Redis 还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大

只做缓存:如果你只希望你的数据在服务器运行的时候存在,关闭服务器就销毁,可以不适用任何的持久化方式

如果同时开启两种持久化:

  在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢?

作者建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份),快速重启,而且不会有AOF可能潜在的bug,留着作为一个万一的手段。

性能建议:

  因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1这条规则。

  如果Enalbe AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

  如果不Enable AOF ,仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个。新浪微博就选用了这种架构

  

  
    

    

时间: 2024-11-07 16:52:16

5.Redis的持久化的相关文章

redis 数据持久化

转:redis 数据持久化 1.快照(snapshots) 缺省情况情况下,Redis把数据快照存放在磁盘上的二进制文件中,文件名为dump.rdb.你可以配置Redis的持久化策略,例如数据集中每N秒钟有超过M次更新,就将数据写入磁盘:或者你可以手工调用命令SAVE或BGSAVE. 数据保存的目录: 工作原理 Redis forks. 子进程开始将数据写到临时RDB文件中. 当子进程完成写RDB文件,用新文件替换老文件. 这种方式可以使Redis使用copy-on-write技术. 2.APP

Redis数据持久化机制AOF原理分析二

Redis数据持久化机制AOF原理分析二 分类: Redis 2014-01-12 15:36  737人阅读  评论(0)  收藏  举报 redis AOF rewrite 目录(?)[+] 本文所引用的源码全部来自Redis2.8.2版本. Redis AOF数据持久化机制的实现相关代码是redis.c, redis.h, aof.c, bio.c, rio.c, config.c 在阅读本文之前请先阅读Redis数据持久化机制AOF原理分析之配置详解文章,了解AOF相关参数的解析,文章链

Redis源码剖析和注释(十八)--- Redis AOF持久化机制

Redis AOF持久化机制 1. AOF持久化介绍 Redis中支持RDB和AOF这两种持久化机制,目的都是避免因进程退出,造成的数据丢失问题. RDB持久化:把当前进程数据生成时间点快照(point-in-time snapshot)保存到硬盘的过程,避免数据意外丢失. AOF持久化:以独立日志的方式记录每次写命令,重启时在重新执行AOF文件中的命令达到恢复数据的目的. Redis RDB持久化机制源码剖析和注释 AOF的使用:在redis.conf配置文件中,将appendonly设置为y

Redis的持久化

Redis的持久化有两种方法 一,RDB:是redis的默认方法,RDB相当于照快照,保存的是一种状态(保存的文件后缀是 rdb) 优点:1.快照保存数据速度极快,还原数据速度极快 2.适用于灾难备份 缺点:1.小内存机器不适合使用. RDB机制符合要求就会照快照.(随时随地的启动),会占用一部分系统资源(突然地), 很可能内存不足直接宕机.(宕机后,服务器会关闭,非正常关闭) 适用于内存比较充裕的计算机. RDB照快照的条件: 1.服务器正常关闭时候,照快照.  ./bin/redis-cli

redis开启持久化

redis的持久化有rdb和aof两种. rdb是记录一段时间内的操作,一盘的配置是一段时间内操作超过多少次就持久化. aof可以实现每次操作都持久化. 这里我们使用aof. 配置方式,打开redis的配置文件.找到appendonly.默认是appendonly no.改成appendonly yes. 再找到appendfsync 默认是: # appendfsync always #每次收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用 appendfsync ever

Redis实战(八)Redis的持久化

Redis相比Memcached的很大一个优势是支持数据的持久化, 通常持久化的场景一个是做数据库使用,另一个是Redis在做缓存服务器时,防止缓存失效. Redis的持久化主要有快照Snapshotting和AOF日志文件两种方式. 前者会根据配置的规则定时将内存中的数据持久化到硬盘上, 后者则是在每次执行写命令之后将命令记录下来. >>RDB方式 Redis是会以快照的形式将数据持久化到磁盘上. 默认会将快照文件存储在Redis当前进程的工作目录的dump.rdb文件中, 可以通过配置文件

Redis的持久化RDB

dbfilename redis.db  //持久化的文件dir /home/redis/6379    //文件所在目录save 900 1    // 900秒 修改一个key就保存一次save 300 10    // 300秒 修改10个key就保存一次save 60 10000    // 60秒 修改10000 个key就保存一次//上述3个save条件应该从下往上看,每个条件都是或的关系rdbcompression yes        //启用压缩rdbchecksum yes 

Redis总结(四)Redis 的持久化

前面已经总结了Redis 的安装和使用今天讲下Redis 的持久化. redis跟memcached类似,都是内存数据库,不过redis支持数据持久化,也就是说redis可以将内存中的数据同步到磁盘来持久化,以确保redis 的数据安全.    redis持久化的两种方式 redis提供了两种持久化的方式,分别是RDB(Redis DataBase)和AOF(Append Only File). RDB,简而言之,就是将存储的数据快照的方式存储到磁盘上, AOF,则是将redis执行过的所有写指

Redis的持久化-AOF

Redis的持久化AOF模式,以日志的形式记录服务器所处理的每一个写操作,在Redis服务启动之初会读取该文件来重新构建数据库,以保证启动后数据库中的数据是完整的. AOF的优点: 1.可以带来更高的数据安全性. 2.由于对日志文件的写入操作采用的是append模式,因此在写入过程汇总即使出现宕机,也不会破坏日志文件中已经存在的内容,然而如果我们本次操作写入一半数据就出现系统崩溃,可以在Redis下一次启动之前,通过redis-check-aof工具帮助解决数据一致性的问题. 3.如果日志过大,

redis修改持久化路径、日志路径、清缓存

redis修改持久化路径和日志路径 vim  redis.conf logfile /data/redis_cache/logs/redis.log    #日志路径 dir /data/redis_cache      #持久化路径,修改后 记得要把dump.rdb持久化文件拷贝到/data/redis_cache下 先杀掉redis,拷贝dump.rdb,启动 清缓存 cd  /data/server/redis-2.6.16/src ./redis-cli    #进入 dbsize fl