Redis持久化方式AOF和RDB

Redis持久化方式:

1、RDB    Redis DB
2、AOF    AppendOnlyFile 默认关闭

RDB方式:

默认情况下,Redis将数据库快照保存在名字为dump.rdb的二进制文件中。
在RDB方式下,有两种保存方式:
(1)、手动执行持久化数据命令来让redis进行一次数据快照。
save:在客户端手动执行save命令,它会阻塞Redis服务,无法响应客户端请求,创建新的dump.rdb替代旧文件
bgsave:它是一个异步命令,非阻塞,Redis服务正常接收处理客户请求,这种方式,Redis会fork()一个新的子进程来创建RDB文件,子进程处理完后会向父进程发送一个信号,通知它处理完毕,然后父进程会用新的dump.rdb文件来替代旧文件
注意:Fork发生时,父进程内存共享,所以为了不影响子进程做数据快照,在这期间修改数据,将会被复制一份,而不进共享内存,所以说:RDB所持久化的数据,是Fork发生时的数据,在这样的条件下进程持久化数据,如果因为某些情况宕机,则会丢失一部分数据,如果在实际生产中对数据丢失没那么敏感,丢失的也可以从传统数据库中获取或者丢失部分也无所谓,那么就可以选择RDB持久化方式。
save和bgsave的比较:
<1>、save不用创建新的进程,速度略快,bgsave需要创建子进程,消费额外的内存
<2>、save适合停机维护,服务低谷时段,bgsave适合线上执行
(2)、另一种则是根据你所配置的配置文件中的策略,达到策略的某些条件时自动持久化数据,和bgsave执行原理相同

    save 900 1
    save 300 10
    save 60 10000

这是配置文件默认的策略,它们之间是或的关系,每个900秒,在这期间变化至少一个键值,做快照。或者每300秒,变化10个键值做快照。或者每60秒,变化10000个键值,做快照。

AOF方式:

append only file,采用追加的方式保存
默认文件是:appendonly.aof
它记录所有的写操作命令,在服务启动的时候使用这些命令可以还原数据库,调整AOF持久化策略,可以在服务出现故障时,不丢失任何数据,也能丢失一秒数据,相对于RDB来说损失小的多。
(1)、AOF写入机制
事实上,AOF机制并不会立即将命令写入到硬盘文件中,而是写入到磁盘缓存,在接下来的策略中,配置多长时间来将硬盘缓存写入到硬盘文件,所以在一定条件下,还是会丢失数据,不过丢失很少一部分。所以AOF方式不能保证绝对不能丢失数据。
(2)、写入磁盘策略
Redis默认使用ervrysec,就是说每秒持久化一次,而always则是每次操作都会立即写入aof文件中,而no则是不主动进行同步操作,是默认30s一次。
Always:服务器每写入一个命令,就调用一个fdatasync,将缓冲区里面的命令写入到硬盘。这中模式下,服务器出现故障,也不会丢失任何已经成功执行的命令数据。
Everysec:服务器每一秒调用一次fdatasync,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,最多只丢失一秒钟内的执行命令数据。
No:服务器不主动调用fdatasync,由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下,服务器遭遇意外故障时,丢失命令的数量是不确定的。
运行速度:always的速度慢,everysec和no都很快。
(3)AOF重写机制:
AOF有序的记录了redis的命令操作,意外情况下丢失数据很少,它不断地对APF文件添加操作日志记录,redis有专门的优化策略来优化日志记录文件过大的问题。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

前者是指超过上一次aof重写aof文件大小的百分之多少,会再次优化,如果没有重写,则以启动时为主,后者是限制了允许重写的最小aof文件大小,bgrewritesof命令是手动重写命令,会fock子进程,在临时文件中重写数据库状态对原apf无任何影响,当重建旧的状态后,也会把fock发生后的一段时间内的数据一并追加到临时文件,最后替换原有的aof文件,新的命令继续向新的aof文件中追加。
重写的过程:
fock一个子进程负载重写AOF文件
子进程会创建一个临时文件写入AOF信息
父进程会开辟一个内存缓冲区接收新的写入命令
子进程重写完成后,父进程会获得一个信号,将父进程接收到的新的写入操作由子进程写入到临时文件中
新文件替换旧文件
注:如果写入操作的时候出现故障导致命令写半截,可以使用redis-check-aof工具修复
AOF重写触发:
手动:客户端向服务器发送BGREWRITEAOF命令
自动:配置文件中配置自动执行BGREWRITEAOF命令

auto-aof-rewrite-min-size &lt;size&gt;
触发AOF重写所需的最小体积:只要在AOF文件的体积大于等于size,才会考虑是否需要进行重写AOF,这个选项用于避免对体积过小的AOF文件重写
auto-aof-rewrite-percentage &lt;percent&gt;
指定触发所需的AOF文件体积的百分比:当AOF文件的体积大于指定的体积,并且超过上一次重写之后的AOF文件体积的percent%时,就会触发AOF重写。这个值设置为0表示关闭自动AOF重写。

举例:

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
appendonly no / yes

当AOF大于64M的时候,可以考虑AOF文件重写
只有当AOF文件的增量大于起始值size的100%时,启动重写, 默认是关闭

RDB和AOF比较:

1、RDB
优点:
完全备份,不同时间的数据集备份可以做到多版本恢复
紧凑的单一文件,方便网络传输,适合容灾恢复
恢复大数据集速度比AOF快
缺点:
会丢失最近写入,修改的未能持久化的数据
fock过程非常耗时,会造成毫秒级不能响应客户端请求
2、AOF
优点:
写入机制,默认是ervrysec每秒执行,性能好不阻塞服务,最多丢失一秒数据
重写机制,优化AOF文件
如果误操作,比如fulshall等,只要AOF未被重写,停止服务,移除AOF文件尾部FUSHALL命令,重启redis,可以将数据集恢复到flushall执行前的状态
缺点:
相同数据集,AOF文件体积比RDB大很多
恢复数据库速度比RDB慢

原文地址:http://blog.51cto.com/7834466/2344544

时间: 2024-10-07 11:03:12

Redis持久化方式AOF和RDB的相关文章

【Redis篇】Redis持久化方式AOF和RDB

一.前述 持久化概念:将数据从掉电易失的内存存放到能够永久存储的设备上. Redis持久化方式RDB(Redis DB)   hdfs:    fsimageAOF(AppendOnlyFile)   hdfs :    edit logs    默认关闭的 二.RDB方式 在默认情况下,Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中 在RDB方式下,有两种方式, 1.一种是手动执行持久化数据命令来让redis进行一次数据快照,而手动执行持久化命令,你依然有两种选择,那就是

20190930-02 Redis持久化方式一:RDB及修改RDB的默认持久化策略 000 032

原文地址:https://www.cnblogs.com/YUJIE666/p/11610744.html

Redis持久化方式RDB与AOF详解

前言 Redis提供了两种数据存储方式,分别是:cache-only && persistence:cache-only顾名知义,是用与缓存服务的,数据在服务器终止后将消失,在此模式下将不存在"数据恢复"的方式,是一种安全性低.效率高.易扩展的模式:persistence即内存中的数据持久备份至磁盘文件中,在服务重启之后能够恢复数据,这种模式下数据的安全性大大提高.cache-only没有什么讲的,这里主要说明Redis的持久化存储模式.对于persistence持久化

redis持久化之AOF

AOF:Append Only File 以io顺序把操作的写命令追加到指定的文件末尾(缺点:文件有可能会变的越来越大) 记录每一次写操作至指定的文件尾部实现持久化: 当redis重启时,可通过重新执行文件中的命令在内存中重建数据库 redis能够合并重写aof的持久化文件,使用bgrewriteaof配置命令实现 bgrewriteaof  --> aof文件重写: 不会读取正在使用的aof文件,而通过将内存中的数据以命令的方式保存到临时文件中,完成之后替换原来的aof文件 通过bgrewri

redis 持久化方式

对于persistence持久化存储,Redis提供了两种持久化方法: Redis DataBase(简称RDB) 执行机制:快照,直接将databases中的key-value的二进制形式存储在了rdb文件中 优点:性能较高(因为是快照,且执行频率比aof低,而且rdb文件中直接存储的是key-values的二进制形式,对于恢复数据也快) 使用单独子进程来进行持久化,主进程不会进行任何IO操作,保证了redis的高性能 缺点:在save配置条件之间若发生宕机,此间的数据会丢失 RDB是间隔一段

redis持久化方式与优缺点

Redis是一个支持持久化的内存数据库,也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化.redis支持四种持久化方式,一是 Snapshotting(快照)也是默认方式:二是Append-only file(缩写aof)的方式:三是虚拟内存方式:四是diskstore方式.下面分别介绍之. (一)Snapshotting 快照是默认的持久化方式.这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb.可以通过配置设置自动做快照持久化的方式.我们可

redis持久化之AOF持久化

AOF与RDB持久化通过保存数据库中的键值对来记录数据库状态不同,aof持久化是通过保存redis服务器所执行的写命令来记录数据库状态的.被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存的. 1.AOF持久化的实现 AOF持久化的实现可以分为命令追加(append),文件写入,文件同步(sync)三个步骤. 1.1 命令追加 当AOF持久化功能处于打开状态,服务器在执行完一个写命令之后,会以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区末尾: struct red

redis 持久化 如果 AOF 文件出错了,怎么办?

服务器可能在程序正在对 AOF 文件进行写入时停机, 如果停机造成了 AOF 文件出错(corrupt), 那么 Redis 在重启时会拒绝载入这个 AOF 文件, 从而确保数据的一致性不会被破坏. 当发生这种情况时, 可以用以下方法来修复出错的 AOF 文件: 为现有的 AOF 文件创建一个备份. 使用 Redis 附带的 redis-check-aof 程序,对原来的 AOF 文件进行修复. $ redis-check-aof --fix (可选)使用 diff -u 对比修复后的 AOF

redis持久化方式

redis的存储分为内存存储.磁盘存储和log文件三部分,配置文件中有三个参数对其进行配置. save seconds updates,save配置,指出在多长时间内,有多少次更新操作,就将数据同步到数据文件.这个可以多个条件配合,比如默认配置文件中的设置,就设置了三个条件. appendonly yes/no ,appendonly配置,指出是否在每次更新操作后进行日志记录,如果不开启,可能会在断电时导致一段时间内的数据丢失.因为redis本身同步数据文件是按上面的save条件来同步的,所以有