redis的持久化方式:RDB和AOF

  • 时间:
  • 浏览:0
  • 来源:大发时时彩代理—大发大发彩票app

一:物理内存足以满足,许多就让dump非常快,性能最好

1.表示否有有开启AOF持久化:

  进入redis安装路径 执行 redis-check-aof --fix AOF配置文件名称

   数据持久化通俗讲否则把数据保存到磁盘上,保证过多再将会断电等因素丢失数据。

      redis支持有四种 持久化法律法律依据,有四种 是 Snapshotting(快照)也是默认法律法律依据,另有四种 是Append-only file(缩写aof)的法律法律依据。

Tip:

      AOF比快照法律法律依据有更好的持久化性,是将会在使用AOF持久化法律法律依据时,redis会将每有一一八个 收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。

根据这点我想要在有一一八个 服务器上开启多个redis节点(利用多CPU),使用aof的持久化法律法律依据。

虽然快照和aof一样,都使用了Copy-on-write技术。多次试验发现每次做数据dump的就让,内存总要扩大一倍,许多就让会有有四种 情況:

save 900 1  #900秒内将会超过有一一八个 key被修改,则发起快照保存

save 30 10 #30秒内容如超过10个key被修改,则发起快照保存save 30 300

    下面是默认的快照保存配置

 

1.Snapshotting(RDB)

     快照和aof虽然都使用Copy-on-write,但有个不同点,快照你无法预测redis那先 就让做dump,aof可不前要通过bgrewriteaof命令控制dump的时机。

     AOF定义:以日志的形式记录每个操作,将Redis执行过的所有指令完全记录下来(读操作不记录),只许追加文件但不可不前要修改文件,Redis启动总要读取AOF配置文件重构数据。

做备份:当数据量大,且对恢复传输带宽有要求,否则数据的一致性要求不高说说,可不前要只使用RDB

  appendfsync everysec (异步操作,每秒记录,将会一秒钟内宕机,有数据丢失)

     另外将会快照法律法律依据是在一定间隔时间做一次的,许多将会redis意外down掉说说,就会丢失最后一次快照后的所有修改。将会应用要求必须丢失任何修改说说,可不前要采用aof持久化法律法律依据。

     当redis重启总要通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然将会os会在内核中缓存 write做的修改,许多将会都在立即写到磁盘上。曾经aof法律法律依据的持久化也还是有将会会丢失累积修改。

 有有四种 法律法律依据如下(默认是:每秒fsync一次)

  定义:AOF采用文件追加的法律法律依据持久化数据,许多文件会必须大,为了出理 许多情況处于,增加了重写机制

      另许多前要注意的是,每次快照持久化都在将内存数据完全写入到磁盘一次,并不 是增量的只同步脏数据。将会数据量大说说,否则写操作比较多,必然会引起少许的磁盘io操作,将会会严重影响性能。

1.当redis前要做持久化时,redis会fork有一一八个 子应用程序

三: 物理内存+虚拟内存必须满足,许多就让dump老要死着,时间久了机器挂掉。许多情況否则灾难!

    不过亲戚亲戚大伙可不前要通过配置文件告诉redis亲戚亲戚大伙想要 通过fsync函数强制os写入到磁盘的时机。

  appendfsync always (同步持久化,每次处于数据变更会被立即记录到磁盘,性能差但数据完全性比较好)

重写AOF文件并必须操作旧的AOF文件,否则将整个内存中的数据内容用命令的法律法律依据重写了有一一八个 新的aof文件(有点痛 类似快照)

      save操作是在主应用程序中保存快照的,将会redis是用有一一八个 主应用程序来出理 所有 client的请求,许多法律法律依据会阻塞所有client请求。许多不推荐使用。

6.RDB与AOF的取舍:

2. 父应用程序继续出理 client请求,子应用程序负责将内存内容写入到临时RDB文件。将会os的写时好友克隆机制(copy on write)父子应用程序会共享相同的物理页面,当父应用程序出理 写请求时os会为父应用程序要修改的页面创建副本,而都在写共享的页面。许多子应用程序的地址空间(地址空间(address space)表示任何有一一八个 计算机实体所占用的内存大小)内的数 据是fork时刻整个数据库的有一一八个 快照。

  appendfsync no  (不同步)

3.当子应用程序完成写临时文件后,将曾经的RDB替换掉,曾经的好处否则可不前要copy-on-writeCopy-on-write 写时好友克隆      在对数据进行修改的就让,过多再直接在曾经的数据位置上进行操作,否则重新找个位置修改,曾经的好处是一旦系统老要断电,重启就让不前要做Fsck.

   auto-aof-rewrite-min-size 64mb

  appendfilename "appendonly.aof"

      client 也可不前要使用save将会bgsave命令通知redis做一次快照持久化。

工作原理:

换句话说,否则Redis重启就会根据日志内容从头到尾执行一次来完成数据的恢复工作。

  appendonly yes(默认no,关闭) 

4.AOF配置文件损坏修复法律法律依据:

  一.RDB与AOF一起开启  默认先加载AOF的配置文件

二:物理内存+虚拟内存可不前要满足,许多就让dump传输带宽会真难,磁盘swap繁忙,服务性能也会下降。所幸的是经过一段比较长的就让数据dump完成了,否则内存恢复正常。许多情況系统稳定性差。

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

3.AOF持久化策略(默认每秒):

  三.AOF运行传输带宽慢于RDB,否则同步策略传输带宽好,不同步传输带宽和RDB相同

  二.相同数据集,AOF文件要远大于RDB文件,恢复传输带宽慢于RDB

菜鸟东哥

  auto-aof-rewrite-percentage 30  (一倍)

       Redis是有四种 高级key-value数据库。它跟memcached类似,不过数据可不前要持久化,否则支持的数据类型很富足。有字符串,链表,集 合和有序集合。支持在服务器端计算集合的并,交和补集(difference)等,还支持多种排序功能。许多Redis也可不前要被看成是有一一八个 数据形态学 服务 器。



2.AOF持久化配置文件的名称:

    默认redis是会以快照的形式将数据持久化到磁盘的(有一一八个 二进 制文件,dump.rdb,许多文件名字可不前要指定),在配置文件中的格式是:save N M表示在N秒之内,redis相当于处于M次修改则redis抓快照到磁盘。当然亲戚亲戚大伙也可不前要手动执行save将会bgsave(异步)做快照。

      Redis的所有数据都在保处于内存中,否则不定期的通过异步法律法律依据保存到磁盘上(这称为“半持久化模式”);也可不前要把每一次数据变化都写入到有一一八个 append only file(aof)上面(这称为“全持久化模式”)。

2.Append-only file(AOF)

      例 如在24G内存的服务器上开启八个节点,每天用bgrewriteaof定期重新派发数据,每个节点dump的时间都在一样,这 样理论上每个节点可不前要消耗6G内存,一共使用18G内存,另外6G内处于单个节点dump时用到,内存一下多利用了6G! 当然节点开的过多内存的利用率也越高。将会传输带宽都在什么的问题,节点数建议 = CPU数。

快速重启,否则过多再又AOF将会潜在的BUG,留作万一的手段。

只做缓存:过多再开启任何的持久化法律法律依据

将会数据要做持久化又想保证稳定性,建议留空一半的物理内存。将会虽然无法接受还是有法律法律依据,下面讲:

本文转自写个博客骗钱博客51CTO博客,原文链接http://blog.51cto.com/dadonggg/1955928如需转载请自行联系原作者

5.AOF的Rewrite(重写) :

两者都开启的建议:RDB数据不实时,一起使用两者时服务器只会找AOF文件,可不可不前要只使用AOF?作者建议不言而喻,将会RDB更适合备份数据库(AOF在不断变化,不好备份)

当AOF文件的大小超过了配置所设置的阙值时,Redis就会启动AOF文件压缩,只保留可不前要恢复数据的最小指令集,可不前要使用命令bgrewriteaof

appendonly yes              //启用aof持久化法律法律依据

# appendfsync always      //每次收到写命令就立即强制写入磁盘,最慢的,否则保证完全的持久化,不推荐使用appendfsync everysec     //每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,推荐# appendfsync no    //完全依赖os,性能最好,持久化没保证

原理:当AOF增长过大时,会fork出二根新的应用程序将文件重写(也是先写临时文件最后rename),遍历新应用程序的内存数据,每条记录有二根set说说。