整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感。 那RDB方式要比AOF方式更加的高效。 获取 redis 的安装目录可以使用 config get dir 命令 RDB优势与劣势 优势 适合大规模的数据恢复 对数据完整性和一致性要求不高 劣势 在一定间隔时间做一次备份,所以如果redis意外 Redis启动的时候就会读取该文件,简而言之,就是将文件中的命令重新执行一遍,完成数据恢复到内存的工作。 如何配置 ? Always ❝每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好 ❞ Appendfsync Everysec ❝出厂默认推荐,异步操作,每秒记录,如果一秒内宕机,有数据丢失 ❞ AOF启动/恢复 正常恢复到内存中 ❝将有数据的aof文件复制一份保存到对应目录,目录路径可以通过config get dir命令获取,重新启动Redis就可以了 ❞ 异常恢复文件到内存中 ❝备份异常AOF文件,使用命令对文件进行修复
我们可以发现有了这样的日志,恢复管理器就能执行灾后恢复,例如系统在进行交易2时,在执行SETINT操作时,系统突然奔溃,下次重启后回复管理器读取日志,它会发现有但是找不到对应的于是这时它就明白交易2在进行过程中发送了错误使得交易没有完成 ,于是就相当于恢复了原来的写操作。 我们再看容灾恢复,每次系统启动时它首先要执行灾后恢复工作。 从上面描述可以看到,恢复管理器严重依赖于日志,因此我们必须确保在数据写入前,日志必须要先完成,如果顺序倒过来,先写入数据,再写入日志,如果写入数据后系统突然奔溃,那么写入信息就不会记录在日志里,那么恢复管理器就不能执行恢复功能了 现在还存在一个问题是,系统运行久了日志会非常庞大,它的数量甚至比数据要大,如果每次恢复都要读取日志,那么恢复流程会越来越久。
因此,设计合理的数据库集群容灾恢复方案成为保障业务连续性的关键技术挑战。 本文基于YashanDB数据库的架构和技术特点,深入探讨数据库集群容灾恢复的设计原则与实现方法,帮助开发人员和数据库管理员建立高可靠、高性能的数据库系统。 容灾恢复设计需充分考虑上述部署形态的特点,针对数据同步、故障检测、节点切换等机制做出针对性的策略制定,以保障核心业务的连续性。 综合容灾恢复设计建议合理选择集群部署形态,根据业务对高可用、扩展性和性能的不同需求,确定单机主备、分布式或共享集群方案。 结论随着数据规模的不断增长和业务对数据库系统连续性要求的提升,容灾恢复设计成为数据库架构不可或缺的组成部分。
数据存储容灾建设主要从数据可靠性和业务稳定性两个维度阐述。这两者有哪些区别呢? 详细架构如下: 1.元数据管理:主要负责集群管理功能,例如路由、卷元数据,集群故障探测以及恢复等管理功能 2.driver接入:主要包括client和agent两部分,client作为块设备在用户侧呈现 如果CBS或者COS分布系统故障时间为分钟级,重试无法解决恢复失效问题,同时会引起机器负载偏高。这里需要针对业务场景来进行设计方案。 方案核心思路主要分为读和写业务。 例如COS如果开启了异地复制,业务可以临时读异地存储桶,虽然存在访问延时,只是影响用户体验,不会造成业务持续不可用;如果是CBS通过挂载新盘通过快照恢复,或者通过使用大内存机器周期性将核心数据读到内存供业务临时访问等等 针对写业务,解决业务有写数据入口,供业务临时写入,等故障恢复了,将盘里新增数据复制到原先存储介质里。这里最常用的就是新增COS和CBS盘的方式让业务进行临时写入,待故障恢复后,补齐数据。
在至少有一个Leader存在的前提下,进行Zookeeper的在线增量、在线减量、在线迁移 在全过程中ZooKeeper不停止服务
云容灾(Cloud Disaster Recovery,简称CDR)是一种基于云计算的灾备解决方案,通过将业务系统和数据备份到云端,实现快速恢复,以确保企业在灾难发生后仍能正常运营。 云容灾不仅提供数据备份功能,还结合计算、存储、网络等云服务能力,允许企业在云端快速部署容灾环境,并进行自动化业务恢复。二、传统容灾 vs. 例如,企业可以通过 API 触发云侧资源区编排、执行容灾演练、监控业务健康状况,并在灾难发生时触发自动化恢复流程,提升灾备响应效率。4. ,该企业通过云容灾方案大幅降低了运维成本,缩短了业务恢复时间,并提升了灾备系统的灵活性和可靠性。 相较于传统容灾方案,云容灾具备高可用性、弹性扩展、自动化管理和智能运维等显著优势,能够有效保障企业在面对突发事件时迅速恢复业务,确保数据安全与业务连续性。
IDC时代,业务对网络容灾参与较少,主要依赖数据中心网络容灾建设程度;当到了云的时代,云服务商将底层网络能力产品化后,云上客户更多参与网络容灾建设,提升业务稳定性。 如果DR之间直通车部分光纤中断,通过“四纤三路由”来快速恢复业务;如果DR之间光纤全部中断,通过BR链路来恢复业务。 2)跨区或者跨地域云基础设施容灾能力。 通常云服务厂家数据中心建设均有容灾能力,这里建议还是选择大厂。 3)IDC到云上网络高可用建设。 混合云容灾模式,这里考虑到IDC和云上线路容灾情况,一般建议两条专线接入不同的POP点来进行容灾建设;同时建立VPN或者GRE公网逃生通道来紧急恢复业务。 image.png 3.2 混合云网络容灾 混合云网络容灾分为两个部分: 1)idc和云机房之间线路容灾,主要线路分为专线和VPN。
在数据级容灾方式下,所建立的异地灾备中心可以简单地把它理解成一个远程的数据备份中心。数据级容灾的恢复时间比较长,但是相比其他容灾级别来讲它的费用比较低,而且构建实施也相对简单。 2.2应用级容灾 应用级容灾是在数据级容灾的基础之上,在备份站点同样构建一套相同的应用系统,通过同步或异步复制技术,这样可以保证关键应用在允许的时间范围内恢复运行,尽可能减少灾难带来的损失,让用户基本感受不到灾难的发生 快速恢复 为即使有传统定制的远程备份,仍然需要时间去做数据的恢复和业务重启,且取决于远程备份的地点远近和远程服务器的性能。而云容灾是可以充分利用云的能力,突破物理限制,在云端做到业务启动。 业务级云容灾:业务级云容灾是指通过云平台做数据的远程备份和恢复,保证关键应用在允许的时间范围内恢复运行,尽可能减少灾难带来的损失,保证一定的RPO和RTO。 Zerto公司的旗舰产品ZertoVirtual Replication (ZVR)是一个基于虚拟机复制的软件解决方案,支持云容灾到AWS和Azure公有云,通过帮助组织机构达到恢复时间目标和恢复点目标而使运作灾难恢复和业务连续性成为可能
2.3 数据库备份服务数据库备份服务拥有一套完整的数据备份和数据恢复解决方案,具备实时增量备份以及快速的数据恢复能力,同时具备异地容灾能力。 4) 使用备份服务恢复在新购数据库恢复数据。注意恢复数据库要求为空库。图片3. 3.2 业务恢复及回切如果云平台自愈能力超出预期,业务在北京地域进行资源1:1的部署恢复。对于数据恢复方式如下:cos数据恢复:cos存储桶异地复制,数据无需恢复。 redis数据恢复:redis通过购买云redis使用之前备份数据进行人工恢复。mysql数据恢复:使用数据库恢复服务进行恢复,详见本文的2.3节。 、存储和数据库备份服务"零"改造自动实现数据恢复自动实现,业务恢复人工实现
为了让企业能更好用好云平台的数据安全能力,本文重点云平台数据备份冷备能力,以腾讯云为例,主要从以下两个维度介绍:同城数据冷备能解决企业什么问题,达到怎么样业务容灾效果? 同城冷备份方案同城数据冷备方案主要依赖于云平台能力备份能力,对现有业务架构没有任何改造,方案架构如下:图片该方案核心要点说明:数据备份:云侧数据库mysql和redis在控制台设置数据备份参数,数据备份存储在COS,具备地域级别容灾 指标详细说明容灾能力具备同地域(不同可用区)数据备份能力,不具备不同地域的能力。 数据备份依赖于云平台的数据备份能力,数据备份和恢复成本几乎为0。业务恢复业务恢复成本较高,1. 业务部署能力,业务恢复依赖于业务测试部署自动化能力。 2.业务验证能力,业务恢复相当于业务重新部署,对于业务全面测试验证上线能力要求较高。3.容灾演练能力建设,增加平时运维成本以及自动化工具开发功能。
备份(Backup)本质定义:在线数据→离线存储的迁移过程核心价值恢复逻辑错误(误删/病毒)保存历史数据版本不可替代性:容灾系统无法修复人为错误4. 灾难恢复(Disaster Recovery)阶段定位:灾难发生后的系统重建与容灾关系:现代容灾系统集成恢复功能二、容灾与备份的协同关系1. 功能互补性2. 典型故障应对案例1:数据库误删操作容灾系统同步删除→需从备份恢复案例2:机房级火灾容灾系统接管业务→备份用于数据追溯三、企业灾备体系规划策略1. 风险评估矩阵2. :微隔离技术增强容灾环境安全性结语构建企业级灾备体系需遵循"预防-响应-恢复"的完整闭环,中科热备作为国产化灾备技术领军者,通过持续创新在金融、医疗、政务等领域成功部署超过2000个案例。 建议企业根据业务特性选择"备份+容灾+恢复"的三维防护策略,定期开展灾备演练,真正实现业务连续性保障。
使用基于云原生的HyperBDR可避免以上问题,它深度对接20+云平台,40+云版本,实现跨架构驱动智能适配,支持高度自动化的异构平台容灾,可自由选择目标云平台进行备份和恢复,方案灵活性更高,可扩展性更强 执行容灾操作 进入容灾工具 HyperBDR 界面 4.1. 容灾配置 在容灾配置页面,勾选需要容灾主机,并点击 容灾配置 按钮,按照容灾配置步骤进行操作。 图片 容灾配置步骤一:指定容灾平台,选择容灾主机所在容灾平台的配置信息,并点击 下一步 按钮 容灾平台信息为空,则表示暂未添加容灾平台,需要 配置容灾平台 ,再进行后续操作。 容灾接管/容灾演练 等待数据同步完成(同步快照完成),勾选需要容灾演练/容灾接管主机,并选择 容灾演练/容灾接管 按钮 容灾演练/容灾接管功能保持一致,此功能则表示将容灾主机在容灾平台进行启动,启动后即可进行相关验证和接管工作 云端API自动化对接,无需预启动实例和预先配置,灾难发生时一键云端拉起业务系统到可用状态,直接恢复到操作系统登录页面,有效缩减RTO。智能驱动预适配,无需人为介入,高度自动化,灾备成功率有保障。
区别:容灾强调的是在灾难发生时,保证系统业务持续不 间断地运行的能力,而灾难恢复强调的灾难之后,系统的恢复能力。 现在的容灾系统都包含着灾难恢复的功能,所以本文的讨论除了包括容灾方面的内容,还包括了 灾难恢复的部分内容。高性能、高可用平台架构的演变过程。 备份是数据高可用的最后一道防线,其目的是为了系统数据崩溃时能够恢复数据。 容灾不可少 那么建设了备份系统,是否就不需要容灾备份系统? 如果是同步容灾,那容灾端同时就删除了;如果是异步容灾,那容灾端在数据异步复制的间隔内就会被删除。这时就需要从备份系统 中取出最新备份,来恢复被错误删除的信息。 备份系统+异地容灾系统 这是一个较为理想化的容灾系统一体化解决方案,能够在很大程度上避免各种可能的错误。 容灾恢复等级 ? 灾难恢复层次 ? 灾备技术层次 ? 1.1 磁盘阵列灾备技术 ?
综上所述,本文从云平台视角出发阐述应用层业务容灾建设,主要分为方案设计考虑纬度、复杂度以及云上客户案例三个方面。 1.应用容灾概述 1.1 应用部署 应用是否满足跨地域/可用区部署? 应用层调用链是否能接受跨区延时,如果业务无法接受跨区,该业务做容灾只能set化部署,这里需要强大中间件团队开发数据同步系统。 应用层调用链能接受跨区延时,一般以试点业务先观察,小步迭代方式逐步构建容灾能力。 容灾切换强依赖于调度系统以及配置系统稳定性。这里稳定性主要包括系统容灾能力和性能;遇到大规模故障,大量信息配置变更请求调度系统和配置系统要能扛住洪峰,是保障这个容灾方案的根基。 2.应用容灾复杂度 计算应用层容灾,主要考虑以下两个方面: 哪些节点执行任务。 这里要区分清楚哪些节点执行核心业务,这里会引入不同的复杂度。
本文结合云平台公网能力,从网络平台角度来分析容灾建设可行性。 2.公网出口容灾方案 2.1 IDC和云平台出口互为主备 正常情况下,IDC和云平台公网出口流量是烟囱式,互不交叉;当IDC公网出口异常,流量切换到云平台,同样云平台公网出口异常,流量切换到IDC。 整体公网出口容灾方案如下: image.png 2.1.1 云平台切换方案。 正常情况下,业务流量通过NAT访问公网,如上路绿色线条标识。 待业务恢复后,在一个业务低峰期时候,通过调用开启和关闭子子网路由来切换。 2.1.2 IDC容灾切换方案 正常情况下,IDC业务流量通过NAT访问公网,如上路绿色线条标识。 IDC公网出口容灾方案 (推荐) 1.方案简单,更多依赖云平台能力 2.方案落地快捷。 3.人力成本低,不需要自建系统。 4.维护成本低,不需要后续维护系统稳定性。
共享存储或数据库主从模式 单元化架构(按用户/业务分片) 成本 专线成本较高,但存储配置可能更简单 异步复制带宽成本相对较低,但架构复杂度和改造成本高 主要优势 高可用、数据零丢失(RPO=0)、故障切换迅速 城市级容灾 2、容灾等级要求:同城双活可应对机房级故障。若需防范城市级灾难(如地震、大规模停电),则需异地双活。 3、成本预算:同城双活专线成本较高,但架构相对简单。
》 现在的公司有责任建立完善的容灾管理体系,当发生不可预见的故障或灾害时,通过成熟的灾难恢复预案实现快速恢复,减少系统服务中断和关键数据丢失,降低业务损失。 3 容灾关键词 RPO(Recovery Point Objective) 数据恢复点目标,主要指的是业务系统最大能容忍的数据丢失量。 容灾体系介绍 1 数据中心 集团公司通过两地建立三个数据中心,通过双活、冷备等方式,实现两地三中心容灾架构。 2 体系建设 系统类型 --- 容灾策略 核心业务系统 --- 两地三活 关键平台系统 --- 同城双活 非关键系统 --- 异地冷备 3 技术方案 异地冷备 恢复能力 RTP≤1h RPO≤5min 容灾演习要求 每年进行容灾演练,所有核心业务与平台系统均要参演。 异地灾备恢复、同城双活切换、一键式自动化启停等恢复方式不断创新,要求演习规模逐年扩大和恢复效率逐年提升。 - End - ----
容我细细细细分析。 原因就是接口挂了,拿不到数据了。那把数据储存起来就可以解决问题。 思考 存哪里? 第一时间反应浏览器本地存储,想起了四兄弟。 接口容灾我们也是刚弄不久,有许多细节与不足,欢迎沟通交流。 接口容灾本意是预防发生接口服务挂了的场景,我们不会很被动。原来是P0的故障,能被它降低为 P2、P3,甚至在某些场景下都不会有用户反馈。
当前,市场上常见的容灾模式可分为同城容灾、异地容灾、双活数据中心、两地三中心几种。 同城容灾 同城容灾是在同城或相近区域内(≤200KM)建立两个数据中心:一个为数据中心,负责日常生产运行;另一个为灾难备份中心,负责在灾难发生后的应用系统运行。 异地容灾 异地容灾主备中心之间的距离较远(>200KM)因此一般采用异步镜像,会有少量的数据丢失。异地灾难备份不仅可以防范火灾、建筑物破坏等可能遇到的风险隐患,还能够防范战争、地震、水灾等风险。 异地灾备中心是指在异地的城市建立一个备份的灾备中心,用于双中心的数据备份,当双中心出现自然灾害等原因而发生故障时,异地灾备中心可以用备份数据进行业务的恢复。 ,所以称为“双活”和“多活”;后者是生产数据中心投入运行,灾备数据中心处在不工作状态,只有当灾难发生时,生产数据中心瘫痪,灾备中心才启动。
在这种场景下,AntDB数据库提供了延迟复制的容灾方案,可以供业务进行快速恢复,给出了一种新的数据恢复解决方案,本文对这种延迟复制的容灾方案进行了探索。 关键词:同步复制;异步复制;延迟复制;数据库参数01数据库容灾概述在业务误删除数据的情况下,可以使用AntDB数据库提供的延迟复制的容灾方案,对误删除数据进行快速恢复,保证业务系统的稳定运行。 03AntDB延迟复制灾备方案的示例本章节介绍了环境信息、搭建主备复制、主备数据一致性验证、延迟复制的设置、延迟复制的验证。 导出的数据可在主库上进行恢复。恢复后的数据保持一致。 AntDB电信级核心交易数据库-服务全国24个省份超10亿用户异步容灾,AntDB的业务不间断数据恢复方案