redis快照与AOF

我们知道,redis的数据是保存在内存里,而内存一断电就没了,所以为了数据持久化,我们得想办法把内存中的数据持久化到硬盘或者另一台机子上。

先说本地持久化到硬盘,这就有两种方式,一是快照(snapshotting),二是只追加文件(append-only file AOF)

快照

快照的核心原理就是把redis在某个时间内存内的所有数据都写入硬盘,那么什么时候写入呢?快照的配置都有哪些呢?
出现下面的情况redis会快照内存里的数据
1 用户发送bgsave命令(此时redis会fork一个子进程,子进程负责生成硬盘文件,父进程负责继续接受命令)
2 用户发送save命令(和bgsave命令不同,发送save命令后,到系统创建快照完成之前系统不会再接收新的命令,换句话说save命令会阻塞后面的命令,而bgsave不会)
3 用户在配置文件了配置了类似这样的命令 
  save 60 1000
  这个的意思是说,自从上次快照成功算起,如果满足"60秒内有1000次写入"这个条件,系统就自动调用bgsave,如果配置文件里有多个save命令,只有满足一个就调用bgsave命令
4 用户发送shutdown,系统会先导员save命令阻塞客户端,然后关闭服务器
5 当有主从架构时,从服务器向主服务器发送sync命令来执行复制操作时,只有主服务器当时没有进行bgsave操作,那么主服务器就会执行bgsave操作。更多的关于主从复制的信息,见下文

快照的配置信息

save 60 1000           
stop-writes-on-bgsave-error no
rdbcompression yes
dbfilename dump.rdb
dir ./
第一个配置不用解释了,第二个看英文就是失败后是否暂停写命令,第三个写的时候是否压缩,第五和第四合起来构成了数据文件的全地址

加入下午3:12分完成了一次快照,一切OK,在4:25开始进行第二次快照,持续了2分钟,一直到4:27次成功生成快照文件。在这2分钟内,系统又更新了35个键。如果在这2分钟内系统发生了崩溃,那么我们就丢失了自3:12以后的所有数据。如果系统在刚完成快照且那35个键还没有写入硬盘时就崩溃了,那我们就丢失了35个键。

快照的优势

快照的文件适合备份
我们建立下面的文件,让他每天凌晨3点执行,就能获得每天redis的版本了

[plain] view
plain copy

  1. #! /bin/bash
  2. PATH=/usr/local/bin:$PATH
  3. redis-cli SAVE
  4. date=$(date +"%Y%m%d")
  5. cp /var/lib/redis/6379/dump.rdb /data01/cache_backup/$date.rdb
  6. echo "done!"

快照的劣势

可能会丢失数据
save 60 1000,如果我在60秒内只更新了800条数据,然后系统崩溃了,那么这800条数据就没了
第二:
大数据量的时候，做RDB，redis服务会暂停近1分钟(20g的物理内存,redis里面有13g的数据)！这个就是redis持久化的时候的服务暂停现象(为啥?创建子进程,子进程的工作不需要资源么?)。
一种方式就是,我关闭自动快照的设置,就是不要写save 10 1000这样的命令,而是在系统不忙的时候发送bgsave,至少我能控制什么时候系统发生停顿么。再或者我发送save,这个虽然会停顿,但是因为不用创建子进程有时候也比较快。

AOF

还有一种就是aof
这是什么呀?就是系统会把所有的redis数据进行的写操作的命令记录到硬盘上,这样一来恢复的时候,再执行一次命令就OK了
它有下面几个设置属性
appendonly no    #是否开启aof 
appendfsync everysec  
no-appendfsync-on-rewrite no
这个配置项是设置在rewrite的时候是否对新的写操作进行fsync(将缓存中的命令写入硬盘)。no表示进行fsync，yes表示不进行默认是设置为no
rewrite是将写操作合并，比如set aa 1; set aa 2; 两个操作应该写成一个操作set aa 2;而什么时候进行rewrite呢?就是aof文件太大的时候
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
appendfsync有三种选择分别是always,everysec,no
always就是每次有一个写命令,就把命令存的硬盘文件里
everysec就是每秒写入硬盘一次
no就是由操作系统来确认什么时候写
我们一般都使用everysec,每秒把写命令写入到硬盘与不进行任何持久化操作在性能上没有什么区别。
aof优势在于:就算出问题了,最多丢失1秒内的更新数据

aof的劣势:

aof文件的体积可能会很大(可能比快照文件还大),另一方面,系统重启的时候回从aof里读命令,如果aof文件太大,读命令也就要还很久
怎么办?系统可以重写aof文件,尽量把文件体积缩小
不过重写的操作也是系统fork一个进程做的,那么在快照里存在的内存占用与性能问题,也会存在。
no-appendfsync-on-rewrite
这个配置项是设置在rewrite的时候是否对新的写操作进行fsync。no表示进行fsync，yes表示不进行
默认是设置为no
重写的时候,get操作是没有问题的,但是如果no-appendfsync-on-rewrite为no,那么写数据就会出现延迟。
我们把no-appendfsync-on-rewrite改成yes,写就没有延迟了

也就是说,aof也是由问题的
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
上面这个两个命令的意思是当现在的aof文件大于64mb,且现在的文件比上一次重写后的文件体积增加了至少100%,那么就立刻重写aof文件。

RDB 和 AOF ,我应该用哪一个？

一般来说,如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。如果你非常关心你的数据,但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。因为以上提到的种种原因， 未来我们可能会将 AOF
和 RDB 整合成单个持久化模型。 （这是一个长期计划。）
(上面两段,复制自:https://my.oschina.net/davehe/blog/174662)

同时使用快照与aof时,当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。

原文地址：https://www.cnblogs.com/miaozhihang/p/9517714.html

时间： 2024-10-09 03:30:09

redis快照与AOF的相关文章

[NoSQL]实验验证redis的快照和AOF

安装配置redis http://www.cnblogs.com/myrunning/p/4222385.html 验证redis的主从复制 http://www.cnblogs.com/myrunning/p/4271167.html 1.1验证redis的快照 1.1.1修改redis配置文件 在这里需要注意一下快照文件保存的路径当前redis用户必须有读写的权限,由于我们当前使用的是root用户,所以不存在读写权限不足的问题. 1.1.2启动redis服务 查看一下是否启动: 1.1.3查

redis RDB 和AOF

参考文献 Redis源码学习-AOF数据持久化原理分析(0) Redis源码学习-AOF数据持久化原理分析(1) Redis · 特性分析 · AOF Rewrite 分析 深入剖析 redis AOF 持久化策略 函数sync.fsync与fdatasync总结整理 redis是一个内存数据库,它将数据保存在自己的内存之中.这意味着如果机器宕机或者断电,将会导致内存中的数据失效.为了能让数据不会出现丢失的情况,redis提供了RDB和AOF两种持久化的功能.接下来讲分别介绍RDB和AOF的原理

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服务正常接收处理客户请求,这种方式,Re

redis++：Redis持久化 rdb & aof 工作原理及流程图 （三）

RDB的原理: 在Redis中RDB持久化的触发分为两种:自己手动触发与Redis定时触发. 针对RDB方式的持久化,手动触发可以使用: 1):save:会阻塞当前Redis服务器,直到持久化完成,线上应该禁止使用. 2):bgsave:该触发方式会fork一个子进程,由子进程负责持久化过程,因此阻塞只会发生在fork子进程的时候. 而自动触发的场景主要是有以下几点: 1):根据我们的 save m n 配置规则自动触发: 2):从节点全量复制时,主节点发送rdb文件给从节点完成复制操作,主节点

Redis快照原理详解

本文对Redis快照的实现过程进行介绍,了解Redis快照实现过程对Redis管理很有帮助. Redis默认会将快照文件存储在Redis当前进程的工作目录中的dump.rdb文件中,可以通过配置dir和dbfilename两个参数分别指定快照文件的存储路径和文件名.快照的过程如下. (1)Redis使用fork函数复制一份当前进程(父进程)的副本(子进程):(2)父进程继续接收并处理客户端发来的命令,而子进程开始将内存中的数据写入硬盘中的临时文件:(3)当子进程写入完所有数据后会用该临时文件替换

Redis解决强制关闭Redis快照导致不能持久化错误

今天在使用composer添加Redis缓存的时候,运行Redis发生错误: 127.0.0.1:6379> set dachou dadachou (error) MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis

Redis的持久化-AOF

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

第十章 Redis持久化--RDB+AOF

注:本文主要参考自<Redis设计与实现> 1.Redis两种持久化方式 RDB 执行机制:快照,直接将databases中的key-value的二进制形式存储在了rdb文件中 优点:性能较高(因为是快照,且执行频率比aof低,而且rdb文件中直接存储的是key-values的二进制形式,对于恢复数据也快) 缺点:在save配置条件之间若发生宕机,此间的数据会丢失 AOF 执行机制:将对数据的每一条修改命令追加到aof文件 优点:数据不容易丢失 缺点:性能较低(每一条修改操作都要追加到aof文

持久化机制(快照和aof)

数据持久化通俗讲就是把数据保存到磁盘上,保证不会因为断电等因素丢失数据.redis需要经常将内存中的数据同步到磁盘来保证持久化.redis支持两种持久化方式,一种是 Snapshotting(快照)也是默认方式,另一种是Append-only file(缩写aof)的方式snapshotting(快照)方式:这种方式是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb(redis的bin目录下).可以通过配置设置自动做快照持久化的方式.我们可以配置redis在n秒内如果超