02 : redis 数据持久化

Redis数据持久化

什么是持久化:

通俗点:就是把redis缓存在内存中的数据保存到磁盘文件里面。

Redis持久化分2种:

RDB 持久化

可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot)。

优点:速度快,适合于用做备份,主从复制也是基于RDB持久化功能实现的。

缺点:会有数据丢失

AOF 持久化

记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存,新命令会被追加到文件的末尾。

优点:可以最大程度保证数据不丢

缺点:日志记录量级比较大

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

一般来说,如果想达到足以媲美 PostgreSQL 的数据安全性, 你应该同时使用两种持久化功能。

如果你非常关心你的数据,但仍然可以承受数分钟以内的数据丢失, 那么你可以只使用 RDB 持久化。

有很多用户单独使用AOF,但是我们并不鼓励这样,因为时常进行RDB快照非常方便于数据库备份,启动速度也较之快,还避免了AOF引擎的bug。

注意:基于这些原因,将来我们可能会统一AOF和RDB为一种单一的持久化模型(长远计划)。

下面的部分将分别介绍两种持久化模型。

1 . RDB 持久化:

rdb持久化核心配置参数:

[[email protected] redis]#vim /nosql/6379/redis.conf

dir /nosql/6379

dbfilename dump.rdb

save 900 1

save 300 10

save 60 10000

配置分别表示:

900秒(15分钟)内有1个更改

300秒(5分钟)内有10个更改

60秒内有10000个更改

RDB持久化高级配置:

stop-writes-on-bgsave-error yes

rdbcompression yes

rdbchecksum yes

dbfilename dump.rdb

dir ./

以上配置分别表示:

后台备份进程出错时,主进程停不停止写入? 主进程不停止容易造成数据不一致

导出的rdb文件是否压缩 如果rdb的大小很大的话建议这么做

导入rbd恢复时数据时,要不要检验rdb的完整性 验证版本是不是一致

导出来的rdb文件名

rdb的放置路径

Rdb快照的运作方式:

当 Redis 需要保存 dump.rdb 文件时, 服务器执行以下操作:

Redis 调用 fork() ,同时拥有父进程和子进程。

子进程将数据集写入到一个临时 RDB 文件中。

当子进程完成对新 RDB 文件的写入时,Redis 用新 RDB 文件替换原来的 RDB 文件,并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制(copy-on-write)机制中获益。

2: AOF 持久化(append-only log file)

appendonly  yes/no

appendfsync always

appendfsync everysec

appendfsync no

配置分别表示:

是否打开aof日志功能

每1个命令,都立即同步到aof

每秒写1次

写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof.

AOF持久化高级配置:

no-appendfsync-on-rewrite yes/no

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

配置分别表示:

正在导出rdb快照的过程中,要不要停止同步aof

aof文件大小比起上次重写时的大小,增长率100%时重写,缺点:业务开始的时候,会重复重写多次。

aof文件,至少超过64M时,重写

我们这里就开启简单的配置就行:

[[email protected] redis]#vim /nosql/6379/redis.conf

appendonly yes

appendfsync everysec

AOF持久化工作原理:

只进行追加操作的文件(append-only file,AOF) 
快照功能并不是非常耐久:如果 Redis 因为某些原因而造成故障停机,那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。尽管对于某些程序来说,数据的耐久性并不是最重要的考虑因素,但是对于那些追求完全耐久能力的程序员来说,快照功能就不太适用了。

从 1.1 版本开始, Redis 增加了一种完全耐久的持久化方式: AOF 持久化。 
你可以通过修改配置文件来打开 AOF 功能: 
appendonly yes 
从现在开始,每当 Redis 执行一个改变数据集的命令式(比如 SET),这个命令就会被追加到 AOF 文件的末尾。 
这样的话,当redis重新启动时,程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的

AOF 重写 :

因为 AOF 的运作方式是不断地将命令追加到文件的末尾,所以随着写入命令的不断增加, AOF 文件的体积也变得越来越大。举个例子,如果你对一个计数器调用了 100 次 INCR ,那么仅仅是为了保存这个计数器的当前值, AOF 文件就需要使用 100 条记录。然而在实际上,只使用一条 SET 命令已经足以保存计数器的当前值了,其余 99 条记录实际上都是多余的。

为了处理这种情况, Redis 支持一种有趣的特性:可以在不断服务客户端的情况下,对 AOF 文件进行重建。执行 BGREWRITEAOF 命令, Redis 将生产一个新的 AOF 文件,这个文件包含重建当前数据集所需的最少命令。

AOF 有多耐久:

你可以配置 Redis 多久才将数据 fsync 到磁盘一次。 
有三个选项: 
每次有新命令追加到 AOF 文件时就执行一次 fsync :非常慢,也非常安全。 
每秒 fsync 一次:足够快(和使用 RDB 持久化差不多,)并且在故障时只会丢失1秒钟的数据。 
从不 fsync :将数据交给操作系统来处理。更快,也更不安全的选择。 
推荐(并且也是默认)的措施为每秒 fsync 一次,这种 fsync 策略可以兼顾速度和安全性。 
总是 fsync 的策略在实际使用中非常慢,即使在 Redis2.0 对相关的程序进行了改进之后仍是如此。频繁调用 fsync 注定了这种策略不可能快得起来。

如果 AOF 文件出错了,怎么办??:

服务器可能在程序正在对AOF文件进行写入时停机,如果停机造成了AOF文件出错,那么 Redis 在重启时会拒绝载入这个 AOF 文件,从而确保数据的一致性不会被破坏。

当发生 AOF 文件出错时,可以用以下方法来修复出错的 AOF 文件:
1、为现有的 AOF 文件创建一个备份。
2、使用 Redis 附带的 redis-check-aof 程序,对原来的AOF 文件进行修复。
redis-check-aof  --fix
3、使用 diff -u  对比修复后的 AOF 文件和原始 AOF 文件的备份,查看两个文件之间的不同之处。
4、重启 Redis 服务器,等待服务器载入修复后的 AOF 文件,并进行数据恢复。

列子:

[[email protected] redis]# redis-check-aof appendonly.aof.bak

AOF analyzed: size=77, ok_up_to=77, diff=0

AOF is valid

[[email protected] redis]#diff -u  appendonly.aof  appendonly.aof.bak

3 .  RDB 和 AOF 之间的相互作用 :

在版本号大于等于 2.4 的 Redis 中, BGSAVE 执行的过程中,不可以执行 BGRWRITEAOF 。 反过来说,在 BGRWRITEAOF 执行的过程中,也不可以执行 BGSAVE 。

这可以防止两个 Redis 后台进程同时对磁盘进行大量的 I/O 操作。 
如果 BGSAVE 正在执行,并且用户显示地调用 BGRWRITEAOF 命令,那么服务器将向用户回复一个 OK 状态,并告知用户, BGRWRITEAOF 已经被预定执行; 一旦 BGSAVE 执行完毕, BGRWRITEAOF 就会正式开始。

当 Redis 启动时,如果 RDB 持久化和 AOF 持久化都被打开了,那么程序会优先使用 AOF 文件来恢复数据集,因为 AOF 文件所保存的数据通常是最完整的。

4 .  备份 Redis 数据:

Redis 对于数据备份是非常友好的,因为你可以在服务器运行的时候对 RDB 文件进行复制: RDB 文件一旦被创建,就不会进行任何修改。

当服务器要创建一个新的 RDB 文件时,它先将文件的内容保存在一个临时文件里面,当临时文件写入完毕时,程序才使用临时文件替换原来的 RDB 文件。

这也就是说,无论何时, 复制 RDB 文件都是绝对安全的。

原文地址:https://www.cnblogs.com/jim-xu/p/11606907.html

时间: 2024-10-16 11:15:28

02 : 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数据持久化

redis使用基础(五) --Redis数据持久化 (转载请附上本文链接--linhxx) 当服务器突然发生问题,或者redis重启,如果希望将数据持久化在硬盘中,下次开启redis还有数据时,redis提供了两种方案,一个叫做RDB(通过内存快照(Snapshotting)实现),另一个叫做AOF(日志追加(Append-only file)).通常结合两种方式来实现redis的持久化. 1.RDB RDB通过内存快照实现,会将redis当前的全部数据以快照的方式写入二进制文件中.实现快照有以

Redis数据持久化

总的来说有两种持久化方案:RDB和AOF RDB方式按照一定的时间间隔对数据集创建基于时间点的快照. AOF方式记录Server收到的写操作到日志文件,在Server重启时通过回放这些写操作来重建数据集.该方式类似于MySQL中基于语句格式的binlog.当日志变大时Redis可在后台重写日志. 若仅期望数据在Server运行期间存在则可禁用两种持久化方案.在同一Redis实例中同时开启AOF和RDB方式的数据持久化方案也是可以的.该情况下Redis重启时AOF文件将用于重建原始数据集,因为叫R

redis数据持久化内存不足

原因:写数据到redis里面写不进去,查看redis日志显示: Can't save in background: fork: Cannot allocate memory 在小内存的进程上做一个fork,不需要太多资源,但当这个进程的内存空间以G为单位时,fork就成为一件很恐怖的操作. 发现问题之后,我先通过sysctl -a查看linux内核参数vm.overcommit_memory(sysctl -a |grep "vm.overcommit_memory"),我们直接修改内

Redis 数据持久化的理解

一.对持久化的理解 Redis 平时的键值对都是在内存中的,但是一旦意外中断或关闭连接,我们将丢失数据. 为了避免这种情况,就有一个持久化的机制,在某种条件下将数据以某种方式转储到文件中,下次启动服务器时可以通过持久化文件恢复数据. 二.持久化的方式 Redis 提供了两种方式,分别是RDB 和 AOF,两者最大的区别是 RDB 存储的是数据库状态(键值对),AOF 则是通过保存 Redis 服务器所执行的命令来记录数据库状态. 三.RDB 3.1 RDB文件的创建与载入 RDB持久化可以手动执

redis 数据持久化 aof方式

打开redis的运行目录,选择数据库2(select 2,是空集)可以看到dump.rdb的上次保存时间是今天中午1:58 添加2条数据: 再查看dump.rdb,保存时间是现在(说明从1:58到现在没有修改过key) 在dump.rdb中可以看到刚才保存进入的数据,但是当添加第三个数据addr3时,dump.rdb的修改时间是不会变的,没有达到快照备份的频率. 现在选择标号为3数据库,添加2条数据,此时还未达到快照持久化的频率,所以默认dump.rdb中还没有这两个数据,dump.rdb的修改

redis学习——数据持久化

一.概述 Redis的强大性能很大程度上都是因为所有数据都是存储在内存中的,然而当Redis重启后,所有存储在内存中的数据将会丢失,在很多情况下是无法容忍这样的事情的.所以,我们需要将内存中的数据持久化!典型的需要持久化数据的场景如下: 将Redis作为数据库使用: 将Redis作为缓存服务器使用,但是缓存miss后会对性能造成很大影响,所有缓存同时失效时会造成服务雪崩,无法响应. 本文介绍Redis所支持的两种数据持久化方式. 二.Redis数据持久化 Redis支持两种数据持久化方式:RDB

Redis基本数据类型、数据持久化、过期策略及淘汰机制

一点技术.技术乐享!!! 如果有人问你:Redis这么快,他的“多线程模式”你了解吗? 请回答他:您是想问Redis这么快,为什么还是单线程模式吗? redis是什么 简单来说redis是C语言开发的一个开源的(遵从BSD协议)高性能键值对(key-value)的内存数据库,可以用作数据库.缓存.消息中间件等. 性能优秀,数据在内存中,读写速度非常快,支持并发10W QPS. 单进程单线程,是线程安全的,采用Io多路复用机制. 丰富的数据类型,支持字符串(string).散列(hash).列表(