Redis持久化--Redis宕机或者出现意外删库导致数据丢失--解决方案

提供了两条命令:

  • save: 在生成快照的时候会阻塞当前 Redis 服务器, Redis 不能处理其他命令。如果
    内存中的数据比较多,会造成Redis长时间的阻塞。生产环境不建议使用这个命令。为了解决这个问题,Redis 提供了第二种方式。
  • bgsave:执行 bgsave 时,Redis 会在后台异步进行快照操作,快照同时还可以响应客户端请
    求。具体操作是 Redis 进程执行fork操作创建子进程(copy-on-write),RDB持久化过程由子进程负责,完成后自动结束。它不会记录fork之后后续的命令。阻塞只发生在fork阶段,一般时间很短。用 lastsave 命令可以查看最近一次成功生成快照的时间。
使用shutdown 持久化

我们先在Redis库中设置如下几个值

set k1 1
set k2 2
set k3 3
set k4 4
set k5 5

操作完成上面的步骤之后我们停止服务器,触发RDB的自动保存save

shutdown

然后再次启动Redis服务

redis-server redis.conf

启动完成,查看我们那些刚刚保存的数据是否被持久化了

keys *

执行完上面的步骤之后,我们可以看到我们的数据都在,就说明我们的触发备份是成功的。

使用flushall模拟数据丢失

该操作有一定的风险性,如果是演示练习按照操作来基本不会出现问题,但是生产上慎重操作。我们做该操作之前,一定要注意先备份RDB对应的持久化问题dump.rdb

先备份dump.rdb

cp dump.rdb dump.rdb.bak

备份完成之后我们确定备份成功在进行下一步操作—清空库

flushall

清空之后我们停止服务器

shutdown

再次启动服务器,查看之前存储的kye

keys *

再次启动查看的时候,我们发现我们的数据丢失了

恢复丢失的数据

停服务器

shutdown

删除我们现有dump.rdb

rm -rf ./dump.rdb

删除成功之后,将我们的备份的dump.rdb.bak重新命名成为dump.rdb

mv dump.rdb.bak dump.rdb

确定之后我们再次启动redis服务

redis-server redis.conf

检查我们之前丢失的数据是否存在

keys *

完成之后我们查看的数据就出现啦!

AOF [Append Only File]

AOF:Redis 默认不开启。AOF采用日志的形式来记录每个写操作,并追加到文件中。开启后,执行更改 Redis 数据的命令时,就会把命令写入到AOF文件中。Redis重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作。

该方式默认关闭,需要使用我们需要修改如下配置

开关 Redis 默认只开启 RDB 持久化,开启 AOF 需要修改为 yes

appendonly no

文件名 路径也是通过 dir 参数配置 config get dir

appendfilename “appendonly.aof”

数据都是实时持久化到磁盘吗?

由于操作系统的缓存机制,AOF数据并没有真正地写入硬盘,而是进入了系统的硬盘缓存。什么时候把缓冲区的内容写入到 AOF 文件?

AOF的保存规则有三种

AOF 持久化策略(硬盘缓存到磁盘),默认 everysec

  • no 表示不执行 fsync,由操作系统保证数据同步到磁盘,速度最快,但是不太安全;
  • always 表示每次写入都执行 fsync,以保证数据同步到磁盘,效率很低;
  • everysec 表示每秒执行一次 fsync,可能会导致丢失这 1s 数据。通常选择 everysec ,
    兼顾安全性和效率。

文件越来越大,怎么办?

由于 AOF 持久化是 Redis 不断将写命令记录到 AOF 文件中,随着 Redis 不断的进行,AOF 的文件会越来越大,文件越大,占用服务器内存越大以及 AOF恢复要求时间越长。
可以使用命令 bgrewriteaof来重写。AOF文件重写并不是对原文件进行重新整理,而是直接读取服务器现有的键值对,然后用一条命令去代替之前记录这个键值对的多条命令,生成一个新的文件后去替换原来的 AOF 文件。

AOF指定大小开始重写

  • auto-aof-rewrite-percentage:默认值为100。aof自动重写配置,当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写,即当aof文件增长到一定大小的时候,Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍(设置为100)时,自动启动新的日志重写过程。

  • auto-aof-rewrite-min-size:默认64M。设置允许重写的最小aof文件大小,避免了达到约定百分比但尺寸仍然很小的情况还要重写。

  • AOF方式的优点

    • AOF 持久化的方法提供了多种的同步频率,即使使用默认的同步频率每秒同步一次,Redis最多也就丢失 1 秒的数据而已。
  • AOF方式的缺点

    • 对于具有相同数据的的Redis,AOF文件通常会比RDF文件体积更大(RDB存的是数据快照)。
    • 虽然 AOF 提供了多种同步的频率,默认情况下,每秒同步一次的频率也具有较高的性能。在高并发的情况下,RDB 比 AOF 具好更好的性能保证。

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)

img

最后如何让自己一步步成为技术专家

说句实话,如果一个打工人不想提升自己,那便没有工作的意义,毕竟大家也没有到养老的年龄。

当你的技术在一步步贴近阿里p7水平的时候,毫无疑问你的薪资肯定会涨,同时你能学到更多更深的技术,交结到更厉害的大牛。

推荐一份Java架构之路必备的学习笔记,内容相当全面!!!

成年人的世界没有容易二字,前段时间刷抖音看到一个程序员连着加班两星期到半夜2点的视频。在这个行业若想要拿高薪除了提高硬实力别无他法。

你知道吗?现在有的应届生实习薪资都已经赶超开发5年的程序员了,实习薪资26K,30K,你没有紧迫感吗?做了这么多年还不如一个应届生,真的非常尴尬!

进了这个行业就不要把没时间学习当借口,这个行业就是要不断学习,不然就只能被裁员。所以,抓紧时间投资自己,多学点技术,眼前困难,往后轻松!

【关注】+【转发】+【点赞】支持我!创作不易!
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
,往后轻松!

【关注】+【转发】+【点赞】支持我!创作不易!
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!

  • 26
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值