Redis持久化-RDB

Redis持久化-RDB

Redis的持久化分为RDB持久化和AOF持久化,本篇文章主要说RDB持久化相关的东西。

RDB持久化就是把当前redis数据库中的数据保存到硬盘的过程。

触发时机

RDB持久化的触发方式有两种,第一种是手动触发,另外一种是自动触发。

手动触发

手动触发RBD主要使用savebgsave命令。其实bgsave是对save命令阻塞问题的优化,因此你应该总是使用bgsave命令。

save

save命令会阻塞当前主进程,直到RDB持久化过程执行完毕,对于内存比较大的实例会造成非常长时间的阻塞,因此线上环境不要使用。

bgsave

bgsave命令执行时,redis主进程会fork出子进程,具体的RDB的过程是由子进程来完成的,在持久化期间,主进程依然响应来自应用程序的命令。阻塞仅仅会发生在fork出子进程的阶段。

自动触发

redis配置文件中使用了save配置

如果在redis配置文件中使用了save m n (表示m秒内进行了n次数据修改)配置,满足情况的时候会触发bgsave

redis集群中从节点执行全量复制操作

从节点执行全量复制操作的时候,主节点会自动触发bgsave命令生存rdb文件并发送给从节点

执行debug reload加载redis

在执行debug reload(这个时候redis实例的run id不会发生变化)重新加载redis的时候,也会自动触发bgsave

默认情况下执行shutdown命令

默认情况下执行shutdown命令,如果没有开启AOF持久化功能,就会自动执行bgsave。

bgsave触发RBD的执行过程

( TODO 后续补充流程图)

  • 主进程执行bgsave命令,首先会检查当前是否存在正在运行的子进程,如果存在的话,bgsave命令就会直接退出。
  • 上述条件满足的情况下,主进程会fork出子进程,在fork操作期间,主进程会短暂的阻塞,可以使用info stats命令的latest_fork_usec选项查看最近一次fork操作所耗费的时间,单位是微秒
  • 父进程fork完成以后,会继续响应来自其他应用程序员的命令(但是save,bgsave,bgrewriteaof这三个命令特殊一些,会有不同的响应方式)
  • 子进程创建RDB文件,由于os的写时复制机制(copy on write)父子进程会共享相同的物理页面,当父进程处理写请求时os会为父进程要修改的页面创建副本,而不是写共享的页面。所以子进程的地址空间内的数 据是fork时刻整个数据库的一个快照。.
  • 当子进程将快照写入临时文件完毕后,用临时文件替换原来的快照文件,并发送信号通知父进程RDB持久化过程完成
  • 父进程收到通知,更新相关的持久化信息

RDB持久化的优缺点

优点

  • 非常适合备份,全量复制等场景
  • redis加载RBD恢复数据会比使用AOF方式恢复的快

缺点

  • 没办法做到实时/准实时的持久化
  • 因为RDB文件是一个压缩过的二进制文件,在redis的版本演进过程中,存在多个格式的RDB格式,因此存在老版本的redis不能完全兼容新版RDB格式的情况

  

                                                   原文链接:https://wenchao.ren/archives/165

时间: 2024-11-05 12:48:22

Redis持久化-RDB的相关文章

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

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

redis持久化RDB和AOF

Redis 持久化: 提供了多种不同级别的持久化方式:一种是RDB,另一种是AOF. RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot). AOF 持久化记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集. AOF 文件中的命令全部以 Redis 协议的格式来保存,新命令会被追加到文件的末尾. Redis 还可以在后台对 AOF 文件进行重写(rewrite),使得 AOF 文件的体积不会超出保存数据集状态所

redis持久化RDB和AOF-转载

Redis 持久化: 提供了多种不同级别的持久化方式:一种是RDB,另一种是AOF. RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot). AOF 持久化记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集. AOF 文件中的命令全部以 Redis 协议的格式来保存,新命令会被追加到文件的末尾. Redis 还可以在后台对 AOF 文件进行重写(rewrite),使得 AOF 文件的体积不会超出保存数据集状态所

Redis 持久化RDB与AOF

Redis 持久化: 提供了多种不同级别的持久化方式:一种是RDB,另一种是AOF. RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot). AOF 持久化记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集. AOF 文件中的命令全部以 Redis 协议的格式来保存,新命令会被追加到文件的末尾. Redis 还可以在后台对 AOF 文件进行重写(rewrite),使得 AOF 文件的体积不会超出保存数据集状态所

redis持久化RDB与AOF

redis持久化 Redis是一种内存型数据库,一旦服务器进程退出,数据库的数据就会丢失,为了解决这个问题,Redis提供了两种持久化的方案,将内存中的数据保存到磁盘中,避免数据的丢失. redis持久化之RDB redis提供了RDB持久化的功能,这个功能可以将redis在内存中的的状态保存到硬盘中,它可以手动执行. 也可以再redis.conf中配置,定期执行. RDB持久化产生的RDB文件是一个经过压缩的二进制文件,这个文件被保存在硬盘中,redis可以通过这个文件还原数据库当时的状态.

redis 之redis持久化rdb与aof

目录2901583663 一.redis持久化之RDB 1.修改配置文件,启动redis服务端 2.保存后关闭redis,生成持久化文件,并 验证持久化生效 二.redis持久化之AOF 1.在配置文件中,添加aof参数 2.准备aof配置文件 redis.conf 3.启动redis服务,添加与验证aof的持久化 三.redis 不重启从rdb持久化切换到aof持久化 1.前提条件是启动的有rdb配置的redis 2.确保redis中有数据 3.开启aof持久化 redis是内存型的数据库 重

redis++:Redis持久化 rdb &amp; aof 工作原理及流程图 (三)

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

Redis持久化RDB、AOF

持久化的意思就是保存,保存到硬盘.第一次接触这个词是在几年前学习EF. 为什么要持久化 redis定义:Redis是一个开源(BSD许可),内存存储的数据结构服务器,可用作数据库,高速缓存和消息队列代理.它支持字符串.哈希表.列表.集合.有序集合,位图,hyperloglogs等数据类型.内置复制.Lua脚本.LRU收回.事务以及不同级别磁盘持久化功能,同时通过Redis Sentinel提供高可用,通过Redis Cluster提供自动分区. 可以看出redis是一个内存的数据库,但是如果re

redis持久化RDB详细操作步骤

1.xshell远程登录服务器ssh [email protected] 2.切换到redis目录 3.创建一个配置文件s2-redis.conf 4.编辑文件 vi s2-redis.conf,写入以下内容 5.检查redis服务端是否是运行状态,此状态属于没有,正常,继续下一步操作 6.指定配置文件启动服务端redis-server s2-redis.conf 7.上面问题解决访问,手动创建没有的目录 8.创建好目录,将目录切换到原来的文件夹redis-4.0.10 [[email prot