文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

什么是RDB和AOF

2024-04-02 19:55

关注

这篇文章主要介绍“什么是RDB和AOF”,在日常操作中,相信很多人在什么是RDB和AOF问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”什么是RDB和AOF”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!

Redis持久化

Redis提供了不同级别的持久化选项:

接下来, 让我们来对比RDB和AOF的优缺点:

RDB优点

RDB缺点

AOF优点

使用AOF持久化程度更高: 你可以配置不同的fsync策略:

注: fsync(https://man7.org/linux/man-pages/man2/fsync.2.html)是系统方法,  用于将内核态的缓存数据持久化到存储设备, 比如将内存数据写入硬盘

默认使用每秒执行一次fsync的策略, 这种场景下, Redis的写性能也能非常好, 因为fsync运行在一个后台线程, 而主线程会尽力完成写操作.  所以你最多丢失1秒钟的数据.

AOF缺点

  1. 鸿蒙官方战略合作共建——HarmonyOS技术社区

  2. 每次AOF被Redis重写的时候,它会从包含在数据集中的实际数据中从头开始重新创建,使新AOF文件对bug的抵抗力比不重写的, ,  一直追加的AOF文件更强.

  3. 在实际使用中, 我们重来没有收到过一个关于AOF文件出错的用户报告.

那我该使用哪个?

通常, 如果你想获得像PostgreSQL那样的数据安全性, 你应该结合RDB和AOF.

如果你非常关心你的数据, 但是允许丢失几分钟的数据, 你可以只使用RDB持久化.

有很多用户只使用AOF, 但是我们不建议那样做, 因为RDB的基于时间点的快照在做数据库备份, 快速重启, 或AOF引擎出现问题时, 非常有用.

注意: 基于这些原因, 在将来(长期计划), 我们最终会统一AOF和RDB为一个持久化模型方案.

下面几节, 我们来举例说明更多, 关于RDB和AOF的细节.

快照

Redis默认保存快照到硬盘上的dump.rdb文件. 你可以配置, 每N分钟, 至少出现了M次数据集改变执行一次快照, 或者手动执行保存 SAVE  或后台保存BGSAVE 命令.

save 60 1000

它是如何工作的?

每当Redis需要保存数据集到磁盘, 会执行下面的任务:

这种方法就是Redis的写即拷语义(copy-on-write)

AOF仅追加文件

快照不是很持久, 如果Redis服务异常停止, 掉电停止, 或者意外执行了kill -9杀掉Redis服务进程, 最后的数据写入将会丢失.  虽然对于有些应用来说这是个小问题, 但对于要求完全持久化的场景, RDB不是一个很好的选择.

appendonly yes

从现在开始, 每当Redis收到一个改变数据集的命令(比如SET), 该操作将追加到AOF文件, 当你重启Redis时,  会基于AOF文件重建数据集.

日志重写

AOF文件大小随着操作的增加而增加. 举个例子, 如果你想递增计数100次, 最终数据集中只包含一个键值就是最终的结果,  但是在AOF文件中有100条记录, 实际上在重建数据集时, 不需要剩余的99次记录.

所以Redis支持这个有趣的功能: 在不中断Redis服务的情况下, 后台进行AOF文件重写. 当执行后台重写命令 BGREWRITEAOF 时,  Reids会将当前内存中的数据集以最短的有序命令集写下来. 如果你使用Redis2.2, 你需要定时执行  BGREWRITEAOF(https://redis.io/commands/bgrewriteaof) , 从Redis2.4开始,  它可以自动触发日志重写(更多信息可以查看2.4的配置示例, 不同版本的配置(https://redis.io/topics/config)).

AOF怎么持久化?

你可以配置时间间隔, Redis来执行fsync到磁盘. 这里有三个策略:

每秒执行一次fsync是建议并且是默认的方式. 它既快又安全. appendfsync always策略在实践中非常慢, 但是支持组提交,  所以可以将多个并行写操作合并, 执行一次fsync即可.

如果AOF文件被截断了应该怎么做?

在写AOF文件时, 服务器出现crash或磁盘空间满了, 这时候AOF依然包含一致的数据,  代表了给定时间点版本的数据集(默认fsync策略可能会丢失1秒的数据), 但是最后的命令在AOF记录中会被截断,  最新的Redis主干版本依然会导入所有的AOF文件内容, 但是会忽略最后的不完整的命令, 这时候, 服务器会发出警告日志:

* Reading RDB preamble from AOF file... * Reading the remaining AOF tail... # !!! Warning: short read while loading the AOF file !!! # !!! Truncating the AOF at offset 439 !!! # AOF loaded anyway because aof-load-truncated is enabled

你可以改变默认配置来强制停止这种事情发生, 但是默认配置会忽略最后这个不完整的命令, 为了保证服务重启后可用.

老版本的Redis不会自动恢复, 需要做以下步骤来恢复:

AOF文件被损坏了怎么办?

如果AOF文件不仅被截断了, 中间还被插入了无效的字节, 事情将变得更加复杂, Redis在启动的时候会中断并提示:

* Reading the remaining AOF tail... # Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix <filename>

最好是用 redis-check-aof 工具修复, 首先不适用 --fix 选项, 找到问题, 跳过该文件的错误位置, 查看是否可以手动修复该文件,  AOF使用与Reids一致的协议格式,所以非常便于手动修复, 否则就使用工具修复该文件, 这种情况, 从无效的位置到文件结束的数据都可能被丢失,  如果损坏位置发生在开头的位置, 则相当于丢失整个数据集.

它是怎样工作的?

日志重写使用了与快照一致的拷贝即写(copy-on-write)的方式, 步骤如下:

怎样从dump.rdb快照切换到AOF

在Redis2.0和Redis2.2用不同的步骤来切换到AOF, 而且Redis2.2切换到AOF更简单, 不需要重启.

Redis >= 2.2

  1. 鸿蒙官方战略合作共建——HarmonyOS技术社区

  2. redis-cli config set save "" #取消RDB

  3. redis-cli config set appendonly yes #开启AOF

第一个配置命令表示启用AOF功能. 这样Redis会阻塞来生成初始的备份, 然后打开新文件来写入操作记录,  后面的写操作将会持续追加到该AOF文件中.

第二个配置命令用来关闭RDB快照持久化. 这是可选的, 如果保留save表示同时使用RDB和AOF持久化.

重要: 记住同时修改redis.conf配置文件来打开AOF, 否则服务重启时将使用原来的配置.

Redis 2.0

在AOF和RDB之间交互

Redis >= 2.4会保证当RDB快照在运行时, 避免触发一个AOF重写进程, 或者当AOF重写已经运行时, 不允许后台保存快照BGSAVE.  这可以防止两个后台进程同时产生高负载的磁盘I/O.

备份Redis数据

开始本节内容前, 请确认已经对数据库进行备份, 如果磁盘损坏, 云实例消失等, 没有备份意味着数据面临着巨大风险, 会消失在"黑洞"  /dev/null中.

Redis对于数据备份非常友好, 即使数据库数据库运行中也允许你对数据进行拷贝备份: RDB文件产生时就不会被修改, 快照备份期间, 它会生成零时的文件,  当快照最终备份完成后采用重命名替换原来的RDB文件.

这意味着服务在运行时, 拷贝RDB文件是非常安全的, 下面是我们的建议:

如果你使用ROF持久化方式, 仍然可以拷贝AOF文件来做备份. 这个AOF文件即使丢失最后一小段数据,  Redis也可以重建它们(请参考上面的截断AOF文件处理方式)

灾难恢复

灾难恢复和备份基本是一致的, 加上可以在许多不同的数据中心间转存这些备份数据. 这种情况下, 即使影响到最主要的数据中心,  其他地方的备份也是安全并且可以恢复的.

针对刚起步, 没有太多的资金来做大型备份, 这里也提供了一些不需要太大开销的灾备恢复技术:

这种方式可能会导致文件传输失败, 所以在传输完成后, 至少要增加文件完整性校验, 比如校验文件大小, 如果使用VPS, 甚至可以使用SHA1校验.

你也需要部署独立的监控报警系统, 对备份过程进行监控, 在备份失败时能及时发现并修复.

到此,关于“什么是RDB和AOF”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注亿速云网站,小编会继续努力为大家带来更多实用的文章!

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-数据库
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯