随着医疗、大型企业行业上云步伐的加快,上云后的业务系统安全性如何保障成为客户关注的重点。对于医疗、大型企业客户,往往建有自己的数据中心,如何保障极端情况下业务系统的稳定运行?双活、灾备,能帮到我们!
越来越多的企业在数字化转型和上云进程中选择混合云的形态(云+自建 IDC 或云+其他厂商云)来进行容灾建设,一方面不会过度依赖单一云厂商,另一方面还能充分利用已有的线下 IDC 资源。
👆点击“博文视点Broadview”,获取更多书讯 《云数据库架构》一书全面介绍了主流数据库的技术特点,结合业务场景讲解了数据库技术选型和数据库架构的最佳实践。下面我们摘取本书第1章中对阿里云RDS MySQL三节点企业版的重点内容,让读者先睹为快。 数据库的高可用是个悠久的话题,目前以最常见的主备模式为例, 它主要有异步和半同步两种方式,但这两种方式都有各自的缺陷。 异步在主库宕机后,最后更新的记录有可能没有推送到从库,从而引发数据丢失。 半同步虽然会保证最少有一个从库接收到binlog,但同样有丢
大家好,我是云英负责存储的研发工程师,杨冠军,很高兴今天能在这里跟大家一起讨论分享下Ceph和Ceph在云英的实践。 首先我先介绍下,Ceph是什么,我们为什么选择Ceph? Ceph是最近开源系统中很火的一个项目,基于Sage Weil的一片博士论文发展而来的一个分布式文件系统,可提供PB级,动态可扩展,数据安全可靠的存储服务。Ceph提供分布式存储服务包括:块存储RBD,对象存储RADOSGW和CephFS三种,基本覆盖了绝大部分企业对存储的需求,所以越来越多企业加入到使用Ceph的行列。在国内也有越来
容灾这个事情,跟多不多云没有任何关系,单个云厂商的公有云里照样可以保障容灾,复杂度还要比多云低一些,也更具备可操作性。
本文根据洪斌10月27日在「3306π」技术 Meetup - 武汉站现场演讲内容整理而成。
Oracle RAC是当前主流的Oracle数据库高可用架构,被众多用户用于核心系统,然而,RAC架构在提供高可用的同时,也面临数据库性能压力这一巨大挑战。性能瓶颈可能出现在RAC架构的网络、处理器等多个领域,但最常见的仍然来自于缓慢的硬盘驱动器。随着应用对更快的随机输入输出需求不断地增加,这些机械硬盘驱动器更难满足这些需求。在此环境下,云和恩墨的超融合存储解决方案——zData Light数据库一体机应运而生:
客户需要将华为云rds for MySQL和天翼云rds for MySQL做一个双向同步,当华为云rds宕机的时候,可以切换到天翼云继续提供服务,而且此时,天翼云的数据也可以自动同步到华为云rds,平时只使用华为云的rds,和双A方案有点差异,需要注意的是rds环境不能安装任何的软件,所以,我目前想到的方案有:
《多机房多活架构,究竟怎么玩?》说明了在机房迁移的过程中,一定有一个“多机房多活”的中间状态:
作者简介 资深前端开发工程师 京东前台技术委员会委员 微信手Q运营产品前端开发组组长 目前负责微信手Q购物入口的前端基础建设及portal开发工作 这篇文章主要讲述了Hawaii框架设计的背景、特
OGG有传统的经典架构,也有最新的微服务,2个都可以远程捕获和应用数据,对数据库服务器是0侵入,而传统的经典架构是纯命令行模式,最新的微服务架构是图形化界面操作,几乎所有操作都可以在界面进行。
但是这篇文章主要讲的是缓存数据库读写顺序问题,并没考虑实际搭建场景,这篇文章面向实际开发应用
本门课程就以华为双活数据中心建设为例,详细分析一下在双活数据中心建设过程中涉及到的端到端六层双活的实现方法。
今天来和大家聊聊双活数据中心解决方案,双活方案中2个数据中心站点之间均为双活特性,在双活数据中心中2个中心同时处于运行状态,同时承担生产业务,可大幅提升整体服务能力和资源利用率。而经常提到的灾备方案中2个数据中心之间的特性为远程复制特性(如时时双写、异步单写)。
MySQL性能压测或者基准测试看起来很简单,使用sysbench,tpcc工具跑跑拿到数据就好,其实压测是一个技术活儿,尤其是涉及到性能对比的测试,因为不同场景/不同厂商的产品的参数设置不同,测试的结果也不一样。如果不阐明具体的参数配置差异,直接给出压测结果可能给其他人带来误导。
热备的情况下,只有主数据中心承担用户的业务,此时备数据中心对主数据中心进行实时的备份,当主数据中心挂掉以后,备数据中心可以自动接管主数据中心的业务,用户的业务不会中断,所以也感觉不到数据中心的切换。
标题中的DBA其实包含两层含义:Database Architect 与 Database Administrator,我在这里都简称DBA了。
2022年,基于对稳定性的焦虑...和思考,交易平台联动中间件平台启动过异地多活项目的探索,虽然完成了核心应用及基础组件的改造,但在疫情&降本增效的影响下并未真正投产,同时也缺乏充分的测试以及线上流量的大规模验证;后续在不断的业务迭代中,相关设计及代码被冲击的面目全非,相关的多活自动化测试case也并没有沉淀下来。
依托于阿里云高速通道专线、事件总线EventBridge和MSHA(Multi-Site High Availability)多活容灾平台,消息队列RocketMQ版提供异地双活功能,通过跨实例间数据的双向同步和业务切流能力,实现业务恢复和故障恢复解耦,保障故障场景下的业务连续性。本文介绍异地双活的概念、应用场景、功能优势、使用限制和计费说明。
A云Polardb-x 1.0现已全面升级为Polardb-x 2.0,但Polardb-X 1.0有其自有特色,仍然有很多企业在使用Polardb-X 1.0方案。那么,当这些企业想将业务系统迁移至腾讯云时,该如何进行数据库选型?怎么样进行数据同步?其中又会涉及到哪些问题呢?
上篇文章《真正的双活产品,不仅仅是实现7×24小时》中,我们介绍了沃趣的同城双活性能,从性能指标来看,已经能够满足企业中对性能要求较高的核心业务。
随着互联网业务快速发展,多IDC的业务支撑能力和要求也逐步提升,行业内的“两地三中心”方案较为流行。
同城双中心+异地灾备中心, “两地三中心”的灾备模式,方案兼具高可用性和灾难备份的能力。
强烈推介IDEA2020.2破解激活,IntelliJ IDEA 注册码,2020.2 IDEA 激活码
作者丨DongGuoChao 来源丨https://blog.dogchao.cn/?p=299 导读:异地多活,作为一种高可用部署架构,成为大中型互联网公司的选择。像大家熟知的大型互联网公司,如阿里
当前,市场上常见的容灾模式可分为同城容灾、异地容灾、双活数据中心、两地三中心几种。
采用高可用系统架构支持重要系统,为关键业务提供7x24的不间断服务,已经成为众多企业保障业务稳定、持续运转的主要选择。服务多活是高可用架构重要实施手段,本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。
最近恰好在搞异地双活,以下是一个梳理: 基本概念 1、异地容灾。这仅仅是一个冷备的概念。也就是在平时正常的时候,另外一个机房只是当做备份。 2、异地双(多)活。而异地双(多)活,却是指有两个或者多个可以同时对外服务的节点,任意一个点挂了,也可以迅速切换到其他节点对外服务,节点之间的数据做到准实时同步。 分类 根据是否需要数据同步大体分为三类: 1、必须同步型。(比如数据库) 2、无须同步型。比如缓存,仅仅是当做缓存,就可以这样做(这个有待商榷,其实缓存也需要同步的,严格来说的话)。 3、只能单活(对全局原
Cell Hashing 由NYGC 技术创新小组与Satija实验室合作开发,使用寡核苷酸标记的抗体标记细胞表面表达的蛋白质,在每个单细胞上放置一个"样本条形码",使不同的样品能够一起多路复用,并在单次实验中运行。欲了解更多信息,请参阅此文[1]
来源:https://blog.dogchao.cn/?p=299 前言 后台服务可以划分为两类,有状态和无状态。高可用对于无状态的应用来说是比较简单的,无状态的应用,只需要通过 F5 或者任何代理
互联网公司发展到一定的规模,系统的高可用就变得极其重要。为了应对那些随时可能发生的意外,“多活”在如今互联网公司好像变得是必备的手段了。甚至一些公司发生一些 P0 事故之后,多活也会出现在 case study 的列表之内。
系统的数据,就是公司的生命。哪怕是狗屎,我们也要将它冷冻起来冰封以备后用。垃圾的产品设计就比较让人费解,会时不时从冰柜中将屎取出,想要品尝其中残留的味道。
点击上方蓝色“程序猿DD”,选择“设为星标” 回复“资源”获取独家整理的学习资料! 后台服务可以划分为两类,有状态和无状态。高可用对于无状态的应用来说是比较简单的,无状态的应用,只需要通过F5或者任何代理的方式就可以很好的解决。后文描述的主要是针对有状态的服务进行分析。服务端进行状态维护主要是通过磁盘或内存进行保存,比如MySQL数据库,redis等内存数据库。除了这两种类型的维护方式,还有jvm的内存的状态维持,但jvm的状态生命周期通常很短。 高可用的一些解决方案 高可用,从发展来看,大致经过了这几个
冷备或者主备并不是一个理想的方案,而且绝大多数情况下,只能是一个心理安慰,真正发生故障的情况下,这样的容灾模式根本起不到作用。
当前,市场上常见的容灾模式可分为本地容灾、同城容灾、异地容灾、双活数据中心、两地三中心几种。
摘要:vSAN延伸集群的出现,不仅使VMware有了自己的存储双活技术,从成本角度来看,更使存储双活这项技术,从“天上”来到了“民间”。 通过vSAN延伸集群加上VMware已有的SRM和VR技术,一个全新的、高效低成本的两地三中心方案应运而生。 上一篇《VMware的灾备与双活----我在vForum 2015分会场的分享(1)》介绍了VMware灾备技术SRM,作为姊妹篇,本次将介绍VMware双活技术。 目前市场上常见的硬件厂商的双活方案通常指的是分布式存储双活,如EMC vPlex, HDS
去年写过一篇《做容灾,冷备是不是个好方案?》,当时提出来,冷备或者主备,其实并不是一个理想的方案,而且绝大多数情况下,只能是一个心理安慰,真正发生故障的情况下,这样的容灾模式根本起不到作用。
数据库这个行业是越来越有意思,参与的PEOPLE 是人山人海,锣鼓喧天,鞭炮齐鸣。 商业数据库 ,开源数据库,国产的数据库, 云原生的数据库 ,云RDS 数据库,已经不是百花齐放的,是星空璀璨。
声明 本文为笔者根据自身的项目经验,以及参考大量文档书写而成。文中提到很多厂商的解决方案和概念,第一不方案之间的优劣评判,第二不进行厂商间的相互攻击,第三文中仅代表个人观点,不代表任何厂商的官方立场。 目前业内主流的双活存储技术 双活这个概念,2013年前后比较火热,那时候笔者有幸参与了IBM的一些双活项目,如GPFS A-A,PowerHA/HyperSwap等。因此本文也是有感而发,经验之谈。 谈到双活,首先这是一个很宽泛的概念。广义上说,双活是两个或多个数据中心,每个都具有独立运行生产应用所需要的所有
接着上篇《做容灾,双活、多活、同城、异地、多云,到底应该怎么选?》,这篇聊聊公有云上应该如何建容灾,跟我们自建机房有什么区别,没看过的同学,建议先从上篇文章看一下。
在软件开发领域,「异地多活」是分布式系统架构设计的一座高峰,很多人经常听过它,但很少人理解其中的原理。
说起容灾,很多同学脑子冒出来熟悉字眼,”同城双活”,“两地三中心”,“单元化”,“set化”等等。其实这些名词背后均隐射一层含义,面对一些灾难时候,业务如何做冗余来快速恢复业务。
腾讯云数据库【国产数据库专题线上技术沙龙】正在火热进行中,4月28日陈爱声的分享已经结束,没来得及参与的小伙伴不用担心,以下就是直播的视频和文字回顾。
在实施微服务的过程中,不免要面临服务的聚合与拆分,当后端服务的拆分相对比较频繁的时候,作为手机 App 来讲,往往需要一个统一的入口,将不同的请求路由到不同的服务,无论后面如何拆分与聚合,对于手机端来讲都是透明的。
我很喜欢的一句话和大家分享一下:很多模式是不能直接复制的。当数量级直线上升的时候,其背后的难度是几何增长的。
相对于过去单体或 SOA 架构,建设微服务架构所依赖的组件发生了改变,因此分析与设计高可用容灾架构方案的思路也随之改变,本文对微服务架构落地过程中的几种常见容灾高可用方案展开分析。
本文由公众号“水滴与银弹”号主Kaito原创分享,原题“搞懂异地多活,看这篇就够了”,为使文章更好理解,有修订。
领取专属 10元无门槛券
手把手带您无忧上云