首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

系列(九)——异地数据冷备建设

异地数据备份挑战相对同城数据备份,异地数据冷备主要挑战是成本,主要是跨地域之数据传输带宽成本。...异地数据冷备方案2.1 API实现方案数据备份:云平台的数据数据备份均为同地域,因此需要将该备份数据上传到异地COS存储桶。...2.3 数据库备份服务数据库备份服务拥有一套完整的数据备份和数据恢复解决方案,具备实时增量备份以及快速的数据恢复能力,同时具备异地能力。...异地数据冷备案例3.1 异地冷备方案以某在线商城为例,涉及数据产品为mysql,reids以及cos,结合云平台的能力,具体方案架构如下:图片方案要点说明:数据备份:基于数据恢复的rto时长,mysql...采用数据库备份服务;当前数据库备份服务暂不支持redis,采用api方式进行备份;cos采用异地存储桶的复制进行数据备份。

8.9K164

异地方案解析

一、异地主要备份三种数据: 1、DB数据 2、操作系统 3、日志信息 二、恢复时间不能超过30分钟 三、图中为DB的备份方式,DB总的有四份备份:生产存储一份、移动硬盘一份、备份存储一份、备存储一份...备份方式为,平时通过生产系统的介质服务器传输到移动硬盘,通过CS传输数据备中心的介质服务器,在通过介质服务器传输到备份存储、备存储。...生产中心发生异常时的DB切换方式为,将移动硬盘迅速转移挂载到备中心的介质服务器,然后再发起恢复 四、日常对OS进行每日备份,通过CS传输到备中心的介质服务器,再发送给备份存储和备存储,即OS的备份有三份...:生产存储、备份存储、备存储 五、日志的备份和OS一样 六、恢复切换步骤:日志恢复、OS恢复、修改IP和主机名、移动硬盘转移挂载 七、本地恢复 image.png 八、两地传输带宽的计算要考虑每日数据增量

2.7K10
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    CKV+异地探索和实践

    今天跟大家分享的题目为《CKV+异地探索和实践》。CKV+是一个兼容redis协议的内存数据库,现在大部分用户对内存数据库的要求越来越高,对一致性、异地等方面也提出更高的要求。...02CKV+数据可用性&一致性的探索和思考 CKV+作为一个内容数据库,在级别的探索上,数据可用性和一致性需要做怎么样的考虑或取舍,有几个点我们必须要先考虑的。...04CKV+单活多可用区异地实践 CKV+为了满足不同的要求,已上线了单活多可用区特性,支持不同级别: 单可用区:机架级能力。 同地域多可用区:机架、可用区级能力。...跨地域多可用区:跨城际。 默认的情况下,CKV+的级别是跨机架,保证主备分片必须跨机架,避免一个机架掉电导致主备分片都不可用的问题。...05CKV+多活架构异地探索 异地单活虽然提供了不同的级别,甚至不同可用区提供了读能力,但只能在主可用区执行写操作。

    1.2K20

    系列(六)——数据存储建设

    数据存储建设主要从数据可靠性和业务稳定性两个维度阐述。这两者有哪些区别呢?...后台数据复制机制能在任何一个副本出现故障时迅速通过数据迁移等方式复制一个新副本,时刻确保有三个副本可用,避免单点故障引起的数据丢失等问题,提高数据的可靠性。...1.2 对象存储(COS) COS将数据分散存储在城市中多个不同的数据中心,其中某数据中心故障了,多AZ存储架构依然可以为云上客户提供稳定可靠的数据服务,云上数据可靠性是12个9,即99.9999999999%...https://cloud.tencent.com/document/product/362/16312 2.将CBS数据上传异地COS,调用cos分块上传接口。...例如COS如果开启了异地复制,业务可以临时读异地存储桶,虽然存在访问延时,只是影响用户体验,不会造成业务持续不可用;如果是CBS通过挂载新盘通过快照恢复,或者通过使用大内存机器周期性将核心数据读到内存供业务临时访问等等

    3.4K73

    同城+异地多活是全球化处理的最好模式吗?

    整理|Penny 编辑|褚杏娟、傅宇琪、Kitty 策划 | QCon 全球软件开发大会 “建设中,关注三个关键词:资源、流量和数据建设强依赖于资源评估。...字节海外 由于海外业务的特殊性,我们的架构首先采用了异地模式,然后发展成为异地加同城的双重模式。...这种模式在初期是一种极简的异地部署模式,其中亚太区域拥有全量数据,而美洲和云上区域也拥有全量数据,但针对不同区域的用户,我们提供业务读取服务,并在本区域内进行写入操作。...正如许多业界公司和从事工作的同事们都知道的,能力的提升是一个持续优化的过程。 在建设中,我们特别关注三个关键词:资源、流量和数据建设强依赖于资源评估。...灾难场景下的逃逸通常会导致一定的数据损失,如何修复数据是我们必须重点关注的问题。 至于国内和海外的差异性,国内可能会根据业务类型选择不同的异地多活部署模式。

    18110

    系列(八)——同城数据冷备建设

    为了让企业能更好用好云平台的数据安全能力,本文重点云平台数据备份冷备能力,以腾讯云为例,主要从以下两个维度介绍:同城数据冷备能解决企业什么问题,达到怎么样业务效果?...云平台对数据冷备能给予企业哪些帮助?1. 数据冷备介绍1.1 数据冷备概念数据冷备,业务数据文件在同地域或者跨地域定时做备份。...,数据备份存储在COS,具备地域级别,RPO依赖于数据库备份周期以及时间。...本文小结同城冷备方案,在云平台的协助下,企业几乎0成本并拥有同城数据冷备能力来保障业务生命线。指标详细说明能力具备同地域(不同可用区)数据备份能力,不具备不同地域的能力。...3.演练能力建设,增加平时运维成本以及自动化工具开发功能。

    6.6K113

    腾讯云原生数据库 TDSQL-C异地核心能力构建

    本文将给大家分享《TDSQL-C (原CynosDB)的实践和探索》,主要内容有以下三个方面: 1 云原生数据库和传统数据库的架构对比 2 MySQL数据库的部署模型 3 TDSQL-C 异地系统的实践...MySQL数据库的部署模型 MySQL数据库常见的部署模型,有以下两种: 跨AZ部署(如上图): 一种是两AZ有三副本,其中AZ1有两副本,AZ2有一个副本;若是四个副本,那么AZ2会再多一个副本...数据一致性以及故障的发现和处理通过外围系统或者内置的一致性协议来保证; TDSQL-C异地系统的实践 (TDSQL-C多维一体的系统) 云原生数据库TDSQL-C在异地能力构建上,近期推出了跨可用实例功能...以上是腾讯云原生数据库TDSQL-C异地系统的实践。...TDSQL-C全球数据库形态,敬请期待 TDSQL-C是计算存储分离的架构,这里主要介绍了计算层的处理机制,而存储层的数据则是依托于HiStor实现的(HiStor是腾讯云分布式块存储产品CBS

    1.9K10

    数据中心精讲(常见的建设模式)

    当前,市场上常见的模式可分为同城异地、双活数据中心、两地三中心几种。...同城 同城是在同城或相近区域内(≤200KM)建立两个数据中心:一个为数据中心,负责日常生产运行;另一个为灾难备份中心,负责在灾难发生后的应用系统运行。...异地 异地主备中心之间的距离较远(>200KM)因此一般采用异步镜像,会有少量的数据丢失。异地灾难备份不仅可以防范火灾、建筑物破坏等可能遇到的风险隐患,还能够防范战争、地震、水灾等风险。...两地三中心 结合近年国内出现的大范围自然灾害,以同城双中心加异地备中心的“两地三中心”的备模式也随之出现,这一方案兼具高可用性和灾难备份的能力。...异地备中心是指在异地的城市建立一个备份的备中心,用于双中心的数据备份,当双中心出现自然灾害等原因而发生故障时,异地备中心可以用备份数据进行业务的恢复。

    2.3K20

    系列(十二)——业务异地多活能力建设【方案篇】

    异地多活相对于异地热备,最大不同点在于应用在不同地域都承载流量,从业务流量调度,数据同步以及业务性能等方面技术复杂度会大幅度的提升。...该方案整体复杂度偏低,资源成本低,不涉及数据同步以及一致性,极端情况下,只能保障部分业务实时提供服务。具体技术架构如下:图片在本方案中,不涉及备份技术方案,详情请参考之前系列的备份方案。...接入层CLB具备跨AZ主备能力;应用层采用多可用区部署建议采用容器运行时;数据层采用一端写就近读的跨AZ高可用实例。3)成本:业务备份的资源成本,具体可参考之前文章系列。...详细技术架构如下:图片在本方案中,不涉及备份技术和AS弹性扩容的技术细节,详情请参考之前系列的备份方案。...方案要点说明如下:1)业务调度:于方案二保持一致1)业务部署:相对于方案二,增加了数据双向同步,各个地域中心均具有全局数据能力,提升的RTO指标,同时不同业务数据要有唯一主键来保证数据一致性。

    2.2K53

    系列(五)——数据库容建设

    在一个数据为王时代,数据安全视为一家企业命根子,因此如何保障企业数据安全尤为重要。本文主要从数据库容方案视角,基于当前客户业务并结合技术&产品,制定最佳方案。...主要从以下三个方面来介绍: 方案设计要素 云上方案 云上客户案例 1.方案设计要素 数据库容方案设计要素主要数据同步,数据一致性以及数据修复三个方面 。...平台方案 客户业务场景最常用腾讯云数据产品主要是redis,cdb,mongoDB以及TDSQL。...数据产品 跨区 就近访问 跨地 CDB 支持 控制台自助配置 支持 跨AZ/跨地域RO实例 方案一:通过DTS支持,需要业务手工切换VIP 方案二:支持DTS双写能力,云上云下或多地域。...,对于2和3的诉求点,结合tdsql产品提供建议。

    8.1K125

    腾讯云原生数据库 TDSQL-C异地核心能力构建

    本文将给大家分享《TDSQL-C (原CynosDB)的实践和探索》,主要内容有以下三个方面: 1 云原生数据库和传统数据库的架构对比 2 MySQL数据库的部署模型 3 TDSQL-C 异地系统的实践...MySQL数据库的部署模型 MySQL数据库常见的部署模型,有以下两种: 跨AZ部署(如上图): 一种是两AZ有三副本,其中AZ1有两副本,AZ2有一个副本;若是四个副本,那么AZ2会再多一个副本...数据一致性以及故障的发现和处理通过外围系统或者内置的一致性协议来保证; TDSQL-C异地系统的实践 (TDSQL-C多维一体的系统) 云原生数据库TDSQL-C在异地能力构建上,近期推出了跨可用实例功能...以上是腾讯云原生数据库TDSQL-C异地系统的实践。...TDSQL-C全球数据库形态,敬请期待 TDSQL-C是计算存储分离的架构,这里主要介绍了计算层的处理机制,而存储层的数据则是依托于HiStor实现的(HiStor是腾讯云分布式块存储产品CBS

    1.9K30

    系列(十)——数据热备能力建设【基础篇】

    由于该方案只做异地数据实时备份,RTO指标依赖于业务部署能力,通常为分钟级。数据热备有两个关键词分别为“异地”和“实时”,需要在再次强调一下。异地明确数据热备能力,实时明确RPO指标接近于“零”。...2)备实例,建议采用云平台的PAAS服务,更好的兼容DTS同步服务。2.2 平台热备方案2.2.1 数据备方案目前数据库对于异地备份能力进行封装,来简化云上客户操作成本,提升RTO。...2.2.3 中间见实时备份方案ckafka云平台在数据同步已支持跨地域,但是对于ckafka版本有要求,为专业版本。...方案关键因素详细说明范围地域级别RPO/RTORPO几乎接近为零;RTO为小时级别,进行1:1业务部署,依赖于业务部署和数据恢复自动化能力。...3.演练能力建设,增加平时运维成本以及自动化工具开发功能。

    5K143

    系列(十一)——数据热备能力建设【进阶篇】

    业务数据备份采用热备方式,指标RPO接近“零”;但是RTO指标还是依赖于业务部署测试自动化能力。业务会进一步需要,在数据热备技术架构下,在成本可控的情况下,是否能进一步提升RTO指标呢?...如果在备地域不仅仅部署数据节点,同时将接入层,服务层均进行部署。极端情况出现后,业务恢复省去资源购买,业务部署时间,大幅度缩减RTO耗时,从本质上可以提升RTO时间。...mysql采用数据同步方式做实时备份,这里未采用数据库自带备实例,主要是由于备实例为只读,不方便平时做演练切换。...方案关键因素详细说明RPO/RTORPO接近为0;RTO分钟级别资源费用备份区实现最小化部署业务改造备份区业务需要适配数据资源地址数据备份依赖于云平台的数据备份能力,数据备份和恢复成本几乎为0。...业务恢复业务恢复成本较低,如果以下两个方面做的充分:1.备区日常业务验证能力,对于业务全面测试验证上线能力要求较高。2.演练能力建设,增加平时运维成本以及自动化工具开发功能。

    5.1K94

    的架构分析和选择策略

    其中,本地的存储网络连接的主备高可用适用于近距离的建设,受距离限制较大;异地远距离的主备高可用,则会存在极小的数据延时。...最为稳固的、保护等级最高,也是成本最高的方案,即“两地三中心”:本地的生产中心和备中心相距100km以上,进行应用级或业务级保护,且在 300km 以外的异地建立备中心,进行数据级或应用级保护...2.1数据 数据是指通过建立异地备中心,做数据的远程备份,在灾难发生之后要确保原有的数据不会丢失或者遭到破坏,但在数据这个级别,发生灾难时应用是会中断的。...在数据方式下,所建立的异地备中心可以简单地把它理解成一个远程的数据备份中心。数据的恢复时间比较长,但是相比其他级别来讲它的费用比较低,而且构建实施也相对简单。...应用级生产中心和异地备中心之间的数据传输是采用异类的广域网传输方式;同时应用级系统需要通过更多的软件来实现,可以使多种应用在灾难发生时可以进行快速切换,确保业务的连续性。

    2.6K30

    同城异地

    序言 同城异地备,主要是用来进行备份的,从而当一个数据中心挂了,另外一个数据中心经过切换之后,能让服务迅速的恢复。...随着业务的进一步发展,需要提供高可用水平,从而需要从单机房扩展为多机房,从而也就有了同城。。。 对于运维来说,多一次升级,多一次变更,就会多一个故障,多一个锅。。。...热升级了解一下,不可预知的中断了解一下 同城异地最关键的点在于存储,存储如何跨机房使用,从而分为几个方面进行探讨: 1、 DNS解析 在业务大量使用DNS解耦的时候,而且使用双机房的时候...核心数据库,要想高可用,并且不存在数据丢失,从而可以使用分布式数据库,在数据写入的时候,采用强同步的方式写入数据,对于master节点,可以采用三机房三中心的模式,使用paxos算法进行选主,从而达到高可用的目标...,并且在数据写入的时候,写入三个分片,从而一个分片的数据损坏,在后台进程中,数据能慢慢的自动弥补回来,从而达到强一致性的数据保存的效果。

    4.1K31

    系列(三)——云网络建设

    网络属于基础设施部分,网络建设作为一个数据中心验收重要指标。试想一个数据中心的网络链路存在单点,就如一个城市道路都是单行道,一旦出现交通事故,小则导致道路拥堵,大则导致整个城市交通瘫痪。...IDC时代,业务对网络参与较少,主要依赖数据中心网络建设程度;当到了云的时代,云服务商将底层网络能力产品化后,云上客户更多参与网络建设,提升业务稳定性。...2.网络复杂度 同城或者异地建设,网络层面因素主要有三个: 1)跨区或者跨地域网络延时,对上层业务影响。 网络延时,通过优化基础设施手段是非常有限的,毕竟受限于实际物理距离和光速。...2)跨区或者跨地域云基础设施能力。 通常云服务厂家数据中心建设均有能力,这里建议还是选择大厂。 3)IDC到云上网络高可用建设。...image.png 3.2 混合云网络 混合云网络分为两个部分: 1)idc和云机房之间线路,主要线路分为专线和VPN。

    4.7K93

    ,双活、多活、同城、异地、多云,到底应该怎么选?

    去年写过一篇《做,冷备是不是个好方案?》,当时提出来,冷备或者主备,其实并不是一个理想的方案,而且绝大多数情况下,只能是一个心理安慰,真正发生故障的情况下,这样的模式根本起不到作用。...最近,公有云又出了些大故障,各大群和朋友圈又开始沸沸扬扬,但是整体看下来,声音无非两种: 单站点不靠谱,要有,出现这种情况就得马上切,所以回去赶紧建设站点; 鸡蛋不能放在一个篮子里,单云不靠谱,...既然要双活,必然会选择另一个跟当前机房有一定距离的机房(同城或异地),而且距离必须得拉开才有意义,如果都在一个园区里面,就没有任何意义了。...我们可以得出的几个结论: 不管怎么选择方案,我们自己的业务系统,从自身架构上,一定要支持单元化,一定要支持数据同步才行,如果这都不支持,讲双活和多活,就是特么的扯淡。...现实情况,比我写的要复杂的多的多,推荐大家看两个成功案例,一个是毕玄的异地多活数据中心,一个是饿了么异地多活,几个关键字google一下就有了,里面涉及到的场景化的细节对大家理解这件事情的复杂度会有更帮助

    2.9K40

    Redis数据备份,恢复手段

    Redis操作是基于内存的,但是它同时又是一个数据库,那么庞大的数据量不可能全部存在内存中。就需要Redis定时将内存中的数据持久化到硬盘上。...整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感。 那RDB方式要比AOF方式更加的高效。...获取 redis 的安装目录可以使用 config get dir 命令 RDB优势与劣势 优势 适合大规模的数据恢复 对数据完整性和一致性要求不高 劣势 在一定间隔时间做一次备份,所以如果redis意外...持久化策略 通过Appendfsync配置 Appendfsync Always ❝每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好 ❞ Appendfsync Everysec ❝出厂默认推荐...everysec异步操作,每秒记录,如果一秒内宕机,仅一秒内的数据丢失 劣势 相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb Aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和

    1.1K42

    ,双活、多活、同城、异地、多云,到底应该怎么选?

    冷备或者主备并不是一个理想的方案,而且绝大多数情况下,只能是一个心理安慰,真正发生故障的情况下,这样的模式根本起不到作用。 原因我就不重复了,大家如果有兴趣可以直接看那篇文章。...最近,公有云又出了些大故障,各大群和朋友圈又开始沸沸扬扬,但是整体看下来,声音无非两种: 单站点不靠谱,要有,出现这种情况就得马上切,所以回去赶紧建设站点; 鸡蛋不能放在一个篮子里,单云不靠谱,...既然要双活,必然会选择另一个跟当前机房有一定距离的机房(同城或异地),而且距离必须得拉开才有意义,如果都在一个园区里面,就没有任何意义了。...我们可以得出的几个结论: 不管怎么选择方案,我们自己的业务系统,从自身架构上,一定要支持单元化,一定要支持数据同步才行,如果这都不支持,讲双活和多活,就是特么的扯淡。...现实情况,比我写的要复杂的多的多,推荐大家看两个成功案例,一个是毕玄的异地多活数据中心,一个是饿了么异地多活,几个关键字google一下就有了,里面涉及到的场景化的细节对大家理解这件事情的复杂度会有更帮助

    2.9K30
    领券