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

本文主要是介绍Redis持久化--Redis宕机或者出现意外删库导致数据丢失--解决方案,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

echo编辑整理,欢迎转载,转载请声明文章来源。欢迎添加echo微信(微信号:t2421499075)交流学习。 百战不败,依不自称常胜,百败不颓,依能奋力前行。——这才是真正的堪称强大!!!


Redis持久化的方案其实是很多人接触的比较少的,因为相对应的数据故障不会很多,一次初始化的设置就能保证后续故障的全部顺利解决。本文讲述一下该机制的主要设置方法和持久化方案的对比,同时也会讲述一些持久化的原理。如果对于Redis持久化比较熟悉的希望能够给到你帮助,如果不熟悉的,你大可参考本文对你的Redis进行设置。

什么是Redis的持久化?

可能很多人很少接触这个词,总觉的我们Redis的所有数据都是全部能够永久存储的。然而你可能不知道的是,Redis的数据都是在内存当中的,如果没有持久化策略,你关闭Redis或者之后,你的数据有可能全部都丢失了。我们每再一次登录Redis访问上一次数据的时候,我们都看到了原来的数据,就是得益于Redis的持久化。Redis的持久化简单说就是,将Redis存在内存中的值存储到可以永久存储的地方(磁盘等)

Redis的持久化方案

  • RDB Redis DataBase
  • AOF Append Only File

RDB [Redis DataBase]

RDB 是 Redis 默认的持久化方案。当满足一定条件的时候,会把当前内存中的数据写入磁盘,生成一个快照文件 dump.rdb。Redis 重启会通过加载 dump.rdb 文件恢复数据。dump.rdb是我们redis文件当中的一个,位置如下图:
www.wityx.com

RDB是怎么实现持久化的

RDB是按照规则来触发持久化存储的,在我们的redis.conf中我们可以看到如下的几个配置:

save 900 1 # 900 秒内至少有一个 key 被修改(包括添加)
save 300 10 # 300 秒内至少有 10 个 key 被修改
save 60 10000 # 60 秒内至少有 10000 个 key 被修改

这几个配置是不冲突的,只要满足任意一个都会触发。

  • RDB方式的优点
    • RDB 是一个紧凑的单一文件,很方便传送到另一个远端数据中心,非常适用于灾难恢复。
    • 与AOF相比,在恢复大的数据集的时候,RDB 方式会更快一些。
  • RDB方式的缺点
    • RDB 方式数据没办法做到实时持久化/秒级持久化。因为 bgsave 每次运行都要
      执行 fork 操作创建子进程,频繁执行成本过高。
    • 在一定间隔时间做一次备份,所以如果 redis 意外 down 掉的话,就会丢失最后
      一次快照之后的所有修改(数据有丢失)。如果数据相对来说比较重要,希望将损失降到最小,则可以使用 AOF 方式进行持久化。

RDB持久化的演示

如果我们都按照正常程序走的话,我们是很难看到没有持久化,或者出现持久化问题的故障现场的。所以我们要学会持久化操作,或者只管看到持久化就需要手动触发持久化问题。这里主要演示两种情况,一种是数据正常备份,一种是数据丢失,我们恢复备份数据。

注意

这两个操作都算是危险操作,我们需要在操作之前进行一下设置一下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 * 

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

恢复丢失的数据
# 停服务器
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的保存规则有三种

www.wityx.com
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 具好更好的性能保证。

两种方案比较

那么对于AOF和RDB两种持久化方式,我们应该如何选择呢?
如果可以忍受一小段时间内数据的丢失,毫无疑问使用 RDB 是最好的,定时生成RDB 快照(snapshot)非常便于进行数据库备份, 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。否则就使用AOF重写。但是一般情况下建议不要单独使用某一种持久化机制,而是应该两种一起用,在这种情况下,当 redis 重启的时候会优先载入 AOF文件来恢复原始
的数据,因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。
---
做一个有底线的博客主

这篇关于Redis持久化--Redis宕机或者出现意外删库导致数据丢失--解决方案的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/986936

相关文章

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

MySQL数据库宕机,启动不起来,教你一招搞定!

作者介绍:老苏,10余年DBA工作运维经验,擅长Oracle、MySQL、PG、Mongodb数据库运维(如安装迁移,性能优化、故障应急处理等)公众号:老苏畅谈运维欢迎关注本人公众号,更多精彩与您分享。 MySQL数据库宕机,数据页损坏问题,启动不起来,该如何排查和解决,本文将为你说明具体的排查过程。 查看MySQL error日志 查看 MySQL error日志,排查哪个表(表空间

【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯,先赞后看哦~🎈🎈 🏆 作者简介:景天科技苑 🏆《头衔》:大厂架构师,华为云开发者社区专家博主,阿里云开发者社区专家博主,CSDN全栈领域优质创作者,掘金优秀博主,51CTO博客专家等。 🏆《博客》:Python全栈,前后端开发,小程序开发,人工智能,js逆向,App逆向,网络系统安全,数据分析,Django,fastapi

安卓链接正常显示,ios#符被转义%23导致链接访问404

原因分析: url中含有特殊字符 中文未编码 都有可能导致URL转换失败,所以需要对url编码处理  如下: guard let allowUrl = webUrl.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed) else {return} 后面发现当url中有#号时,会被误伤转义为%23,导致链接无法访问

零基础学习Redis(10) -- zset类型命令使用

zset是有序集合,内部除了存储元素外,还会存储一个score,存储在zset中的元素会按照score的大小升序排列,不同元素的score可以重复,score相同的元素会按照元素的字典序排列。 1. zset常用命令 1.1 zadd  zadd key [NX | XX] [GT | LT]   [CH] [INCR] score member [score member ...]