Redis -- 03 持久化

Redis提供了两种不同的方法来将数据存储到硬盘里面,一种叫内存快照,另一种叫只追加文件(AOF),这两种方法既可以同时使用课可以单独使用,也可以都不使用,取决于场景。

快照

快照是将某一时刻的所有数据都写入硬盘里面,用作服务器重启是还原数据用。在创建完快照文件之后,可以将快照文件复制到其他服务器上进行备份,或者复制到其他服务器上并启动redis实例建立一个具有相同数据的redis服务器副本。

在redis中启用快照的配置如下:

----------------快照设置start-------------------------------

save 60 1000   --在60s内有1000条写入就执行快照,该配置可以设置多次,满足其中一条即开始快照,一条以上就启用快照功能

stop-writes-on-bgsave-error no   --如果快照写入失败(由于某些原因),Redis是否停止接收写操作(是或否)

rdbcompression yes  // 是否使用LZF压缩STRING当写入rdb的时候

rdbchecksum yes // 是否对rdb进行CRC64校验

dir ./  -- 快照写到什么地方

dbfilename dump.rdb   -- 内存快照的文件名

----------------快照设置end--------------------------------

快照的执行方式是bgsave命令,当满足save条件是就执行这个命令,也可以手动执行这个命令  windows平台不支持bgsave命令

bgsave会创建一个子进程来讲数据从内存写入到硬盘里,而父进程继续处理命令请求

当redis通过shutdown或者受到term信号需要关闭时会执行一次save命令,执行完后再关闭进程

AOF文件

AOF文件是将被执行的写命令复制到硬盘里面,追加到aof文件的末尾,所以,redis只要从头到尾执行一遍aof文件就可以恢复aof文件所记录的数据集

启用aof的配置如下

-----------------------AOF start---------------------------------

appendonly no   --是否开启aof

appendfsync everysec   -- aof文件的同步频率,取值为 always(每次写操作同步),everysec(每秒钟),no(由操作系统决定什么时候写入)

no-appendfsync-on-rewrite no -- 是否在aof文件重写期间调用fsync

appendfilename "appendonly.aof" // aof文件名

auto-aof-rewrite-percentage 100 -- 指定重写aof文件的条件,超过上次rewrite文件大小的百分比

auto-aof-rewrite-min-size 64mb --指定重写aof文件的条件,达到这个大小时才可以重写  auto-aof-rewrite-percentage  和 auto-aof-rewrite-min-size条件必须同时满足

aof-load-truncated yes // redis在启动时可以加载被截断的AOF文件,而不需要先执行 redis-check-aof

dir./   -- 文件所在的目录

-----------------------AOF end----------------------------------

重写aof文件:随着时间的迁移,aof文件会越来越大,但它其实不需要这么大,所以就要对aof文件进行一次重写,就是将内存里面的数据重新生成一份命令列表,写入aof文件中

重写aof文件的命令是bgrewriteaof ,他也是创建一个子进程进行 aof文件的重写操作。 bgrewriteaof 命令也可以自动执行通过哦诶之auto-apf-rewrite的配置

时间: 2024-12-16 16:13:35

Redis -- 03 持久化的相关文章

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.如果日志过大,