主备、冷备、热备、双活、多活、同城、异地、多云，等等等等，这些保证业务高可用和容灾名词，我们经常会听到，不绝于耳。 但是，真的当我们自己要去建设，选择方案时，就发现不知道该怎么选择和搭配了。...结合近期我们的一些讨论，准备用几篇文章简单分享下我们的理解，今天先聊冷备。 冷备是不是个好方案？...理论上，只要有状态的数据（也就是各类分布式服务，如数据库、缓存、消息等组件）同步好，接入层流量能够灵活调度，当出现问题的时候，切入口流量，就可以顺畅的切过去。...但是我们仍然要经过一些详细的论证，从其它角度看是否有解。 从另外一个角度的论证过程 当时我们讨论在冷备的前提下，应该怎么保证系统的可用性，没想到，论证的过程，反而进一步证实了冷备只是一个美好的愿望。...最后，结论 冷备只能是冷备，关键时刻并不能起到快速承载业务的效果，在业务容灾建设时，这个思路其实是不可行的。 但是对于部分组件，比如数据库、大数据、文件，这些存储类的部件，做冷备是有重大意义的。
一、灾备一体机的现状灾备一体机是集软件和硬件于一体的灾备解决方案。灾备一体机的出现，为用户提供了集“计算+存储+灾备”三位一体的解决方案。...与传统的灾备方案相比，灾备一体机将传统备份系统需要的软件、服务器、存储介质和操作系统整合为一体，可有效降低用户成本,又可以减少运维成本。...尽管对比传统灾备中心的优势非常明显，但灾备一体机还是有待解决的问题。灾备一体机的成本，根据用户实际情况，一般需要一次性投入几万到几十万，而部署周期至少会在一到两周的时间。...用户对灾备一体机的硬件是一次性买断，配置冗余，且后续的运维是用户自己在承担。对用户来说，这种付费模式的风险也是很大的。单机难以避免的硬件故障问题，会造成备份失败或数据丢失。...四、总结从这个案例看，HperBDR云容灾可以显著降低灾备成本，同时也放低了灾备门槛，让之前无法实现灾备方案的企业可以满足灾备需求。
今天晚上，他们将在这里开始一年一度的灾备切换演练，11个部室和8个分支行验证机构参与，演练范围包括核心业务系统、柜面系统、二代支付系统等23个重要业务系统和核心骨干网络。...为响应银保监会严格的监管要求，赣州银行建立了完备的两地三中心灾备体系，并且每年都会进行真实的灾备切换演练。 叶光芳是赣州银行系统数据库团队负责人。每年，他都要参与灾备切换演练。...“我们的生产环境运行于虚拟化双活云平台，在正常情况下，可以在线将虚拟机迁移至同城灾备中心，但灾备切换演练时一般是模拟灾难发生，需要进行停机切换，回切时再进行在线回切。”叶光芳介绍道。...但如何把这些自动化的操作，快速的编排成一个整体的流程，是一个难题。于是，赣州银行通过与嘉为蓝鲸的合作，共研灾备切换管理SaaS系统。 跨应用的灾备切换，复杂程度非常高。...灾备切换管理SaaS，能够快速编排出整体的灾备切换方案，并一键自动化的执行所有操作。同时，还引入了可视化技术，通过大屏直观展示实时切换过程，几百项演练操作步骤高效执行。
这个双十一，我们为您带来了程序员专属装备清单， 一起来打造一个属于程序员的世界。 1....屏幕支架 实用指数：★★★★★ 装X 指数：★★★★★ 程序员们为了实现一个方法，修改一个Bug, 经常一坐就是四五个小时，时间久了会有腰膝酸软，下肢无力的感觉，是不是肾透支了？...机械键盘 实用指数：★★★★★ 装X 指数：★★★☆☆ 具非官方统计：好的机械键盘可以让程序员写出的代码简洁优雅2.17倍，速度提升0.24倍。...买到心仪键盘的程序员如此描述： 下按时的感觉像踩到及膝深的雪地，破过一层脆脆地薄冰后就刷一声自动沉到底，但是手指一挪开，按键又很快的弹上来，打字快了的时候，感觉手指只要触碰一下按键表面就跳走，这种快感，...固态硬盘（SSD） 实用指数：★★★★★ 装X 指数：★★★☆☆ 快，不一定不好。飞一般的速度是怎样的一种体验？给电脑换上SSD你就知道了。 原来，打开Eclipse要半个小时。
今天分享一些关于灾备的概念与实践，希望大家有收获。 - 为什么要做灾备？ - 当时开始要做灾备的原因，是因为有一次机房A故障了，大部分的服务都不可以用：时长上涨、接口失败。...假如有一个服务（集群）挂了，有另一个地方的同一个服务（集群）可以继续使用。 灾备分主备和双活两种部署。假设有两个机房 A、B。...一、业务梳理 个人觉得，对于业务方来说，做一个应用的灾备最重要的一点就是业务梳理。...理由如下： 1、达到需要做灾备的业务，通常都是存活了有一定时间的业务，这些业务都会由于各种因素而有一些在做灾备时觉得不合理的设计，简称历史原因。...灾备不脱离业务 - 众所周知，开发大部分的时间都需要赶需求，一方面需求多到无法挤出时间完成灾备的任务，另一方面灾备工作如果不完成，出现故障之后就会影响业务了。
题目部分 基于数据库的数据复制技术构建灾备方案有哪些？ 答案部分 基于数据库的数据复制技术大体上可分为两类：数据库自己提供的数据容灾模块和第三方厂商提供的数据库复制技术。...与最大保护模式一样，日志数据需同时写到源数据库的联机日志文件和至少一个备库的备用日志文件（standby redo log），事务才能提交，与最大保护模式不同的是，如果主库日志数据不能写到至少一个备库的备用日志文件...所有复制对象结构（DDL）的改变，都必须通过Oracle提供的复制包来实施 基于日志挖掘 主要用途 灾备恢复、高可用性 数据共享 数据同步 高可用与容灾、实时数据集成 实现简易程度 实现过程和管理简单...Master Site 支持一对一、一对多、多对一、双向复制等多种拓扑结构 是否支持操作系统异构 不支持 支持，但是有限制 支持 收费情况 免费 免费 免费 收费 1.3 适用场景 数据库类应用容灾产品...经过对以上几种数据库复制技术的分析，DataGuard、Stream、Advenced Replication是专为Oracle数据库开发的灾备模块，适合于同构平台的Oracle数据库容灾；Shareplex
每年一次的双十一大促临近，因此上周末公司组织了一次技术交流闭门会，邀请了电商、物流、文娱内容、生活服务等知名一线互联网公司的技术大牛，一起探讨了一些大促稳定性保障相关的技术话题。...，为了避免和线上不一致，可通过一套标准的脚本来进行检查配置； 弹性伸缩容：设置动态扩缩容，超过固定的比例阈值，进行动态扩容（双十一零点峰值时候慎用）； 云资源保障方面，和云厂商提前沟通，尽可能将没有大促业务的公司服务器资源和自己公司放在同一个可用区或机房...，计算层便于扩容，将DB节点放到容器中，有需要扩容； 2）灾备：对于大流量读场景可通过流量切换方式，将部分流量迁移到备份集群分流； 3）巡检：慢SQL是常见的问题，可通过自动监控和历史数据分析，提供辅助式决策...数据库层也需要做好监控； 比较好的实践是双机热备，在数据同步方面需要有专门的保障机制； 5、高并发下，MySQL主备同步会有较大延迟，该如何处理？...1）双十一零点的前半小时， 做一个动态推送，把日志关掉； 2）真正流量来的时候，留一台机器来观察错误和异常的日志； 隔离 隔离：核心业务和非核心业务做隔离； 身份识别和业务隔离： 1）RPC group
传统的灾备切换演练往往存在缺乏统一的视图管理、沟通环节多、切换步骤复杂、切换效率低等问题，这将无法满足真实场景下业务连续性的灾备切换时效要求。...本次借助嘉为蓝鲸的SaaS平台，落地一键式灾备切换场景，在提升自动化运维水平的同时，进一步保障灾备切换步骤的准确性及时效性，全面满足监管机构的演练要求。...五、PaaS技术平台体系构建 嘉为蓝鲸SaaS平台将演练的环节以图形的方式串联起来，对涉及切换的业务系统及数据库等何时停止、切换和启动等系列动作进行统一的调度和编排，从而清晰且直观地呈现灾备演练过程。...实现灾备切换一览无遗，全局进度尽在掌握，为决策和计划执行提供可视化、高效化的有力支撑。通过清晰的灾备演练过程编排，提高了厦门国际银行灾备演练整体的切换速度和演练流程的清晰度。...本次厦门国际银行与嘉为蓝鲸深度合作，打造一键式灾备切换SaaS应用，通过蓝鲸平台对各个业务系统的切换进行整合、编排、操作，全过程标准化、自动化、流程化、可视化，实现了分钟级切换的一键式灾备切换，极大地提升了灾备演练执行能力和管理水平
架构特性 逻辑数据中心架构 在双十一大促当天业务量年年翻番的情况下，支付宝面临的考验也越来越大：系统的容量越来越大，服务器、网络、数据库、机房都随之扩展，这带来了一些比较大的问题，比如系统规模越来越大，...能够提供支持异地伸缩的能力，提供N+1的灾备方案，提供整体性的故障恢复体系。...整个系统的水平可伸缩性大大提高，不再依赖同城IDC； 可以实现N+1的异地灾备策略，大大缩减灾备成本，同时确保灾备设施真实可用； 整个系统已无单点存在，大大提升了整体的高可用性；同城和异地部署的多个单元可用作互备的容灾设施...在可用性方面，与金融云账务体系深度结合，借用账务系统的failover能力，使得蚂蚁花呗通过低成本改造就具备了同城灾备、异地灾备等高可用能力。...任何一个单元的数据库出了问题、能够快速进行容灾切换、不会影响这个单元的用户进行蚂蚁花呗支付。
架构特性 逻辑数据中心架构 在双十一大促当天业务量年年翻番的情况下，支付宝面临的考验也越来越大：系统的容量越来越大，服务器、网络、数据库、机房都随之扩展，这带来了一些比较大的问题，比如系统规模越来越大，...能够提供支持异地伸缩的能力，提供 N+1 的灾备方案，提供整体性的故障恢复体系。...整个系统的水平可伸缩性大大提高，不再依赖同城 IDC； 可以实现 N+1 的异地灾备策略，大大缩减灾备成本，同时确保灾备设施真实可用； 整个系统已无单点存在，大大提升了整体的高可用性；同城和异地部署的多个单元可用作互备的容灾设施...在可用性方面，与金融云账务体系深度结合，借用账务系统的 failover 能力，使得蚂蚁花呗通过低成本改造就具备了同城灾备、异地灾备等高可用能力。...任何一个单元的数据库出了问题、能够快速进行容灾切换、不会影响这个单元的用户进行蚂蚁花呗支付。
在客户容灾方案建设过程中，客户侧迁移数据库实例到云上MySQL是一个非常普遍的需求。...目前最常用的迁移通用方案是较成熟的方案，一般迁移过程都可以采用此方案；但通用方案存在一个不方便之处：迁移过程中的业务切换是一个难点，调整业务数据库连接配置，将读写数据源切换为CDB实例的IP。...调整业务数据库连接配置这一步很可能存储遗漏的情况，前端业务在长时间的发展过程中，存在多个连接数据库的源，一次性调整访问源到目标是比较困难的。...一般切换方案： 其中图中的第3步，要求业务侧修改指向MySQL的IP。 本方案提供一种迁移方案：通过直接修改数据库的连接IP，实现快速业务切换，避免业务前端重新指向IP。...本方案： HHA是MySQL 高可用方面相对成熟的解决方案，本文中举例说明，代表客户自建数据库。
而每一次的11.11都是对JDOS系统的一次检验和挑战，经过无数次的紧张演练，问题排查，系统升级优化，服务应用快速交付；从容支撑大促高峰流量，保障了业务的高速发展。 全力保障双十一，集群平台来助力。...随着业务量的增长对系统的稳定性要求也将越高，呼叫中心主要对语音呼叫系统及网络进行了11.11前的功能灾备演练工作。...语音系统此次主要针对呼叫中心的电话语音系统、录音系统、办公电话、电话会议等系统做了设备重启，功能模块灾备，系统性能进行了演练压测，保障各系统的稳定性。...统筹资源，夯实基础， 全力保障双十一。...数据库技术部 数据库技术部对数据库系统进行优化和智能化改造，通过智能分析预测技术，在大促前对资源进行合理调度；通过对监控升级，在大促期间应对高峰及时预警；通过接入ContainerFS对备份系统升级，在事后灾备方面做好切换及恢复的准备和方案
，数据库可用双活，但是数据一致性不能完全保证，维护难度较高；数据库物理复制对系统环境要求高，要求相同的数据库版本，相同的操作系统平台，备库只能以只读模式打开；逻辑卷方式效率较差，一般情况下不会用来做数据库容灾方案...；存储复制数据一致性高，效率好，但是备库不可用，有可能把主库的磁盘坏块也复制过去。...在数据库灾备解决方案中，使用阿里云DTS可实现各数据库间的数据迁移与实时同步，从而为数据库灾备打好最重要的基础。...在数据库灾备解决方案中可使用阿里云DBS实现各数据库间的数据备份。...混合云存储阵列还能和传统备份软件（Veritas，Commvault等）结合，作为传统备份软件的备份存储，把备份数据推送上云，实现文件、图片、数据库的统一灾备和备份解决方案。
对于容灾的处理的前提是，当发生灾难后通用的方法是把陷入灾难的单元的流量打到正常的单元上去，这个过程叫做切流量。支付宝架构灾备有三个层次： 1. 同机房单元间灾备 2. 同城机房间灾备 3....异地机房间灾备 对于灾难来说，最小的灾难是某个单元由于插座断开，线路老化，人为误操作等导致宕机，由于每组RZ都有A，B两个单元，可以用来做同机房灾备，并且AB之间是双活双备，正常AB两个单元共同分担所有请求...，一旦A挂了，B将自动承担A单元流量份额，是默认灾备方案。...真实情况下，并不是在发生灾难时才进行切流量，而是事先配置好预案，推送给客户端，或者集成到spanner。 异地机房容灾方案和同机房灾备方案基本一致。...当然除了单元化和OB的方案，支付宝还做了其他一些事情，比如双十一的缓存预热，削峰运营数据，压测容量规划等技术手段。其他互联网公司可以借鉴下。
传统主备模式的缺点 出于灾备（Disaster Recovery）的目的，一般都会建设2个（或多个）数据中心。...传统主备模式是一个业务只在一个数据中心运行，企业结合灾备等级需求和业务需求，在备份中心部署了大量的备份服务器，但备份中心仅为该业务提供灾备服务，只有当灾难发生、生产数据中心瘫痪时，灾备中心的业务系统才启动这些服务器...而一个灾备中心的模式，如果生产数据中心瘫痪，需要半个小时、甚至两个小时、甚至更长时间才能启动灾备中心，在启动灾备中心的时间里，用户交易会严重受损。 双活数据中心的最大优势是有效利用资源。...双活数据中心的建设三个条件 双活数据中心的建设首先要满足三个条件，第一个是应用双活，也就是说数据库一定要实现双活，第二个是网络要双活，业务网络要保证能够同时联通两个数据中心，第三个是数据要双活，两边的数据要能够实现被独立使用...使用户很难取舍那一个是唯一的生产数据，那一个是将要废掉的非生产数据。这就是早年veritas VVR解决方案退出灾备舞台的原因之一。
数据灾备的重要性 有的同学可能会问：我的数据库已经是主从结构、集群化架构了啊。如果有部分节点挂了，数据还是好的呀。这样做是不是就已经ok了呢？ 我可以很明确的说：还不够！...即使你是一家创业公司，也一样如此！在介绍一些灾备方案之前，我们先来说说数据灾备的重要性，我们为什么一定要做灾备？为什么你是创业公司，也一样是第一重要的事情！...具体方案的制定上，你需要思考两个问题： 第一个问题：哪些数据要灾备 虽然现在云服务的存储不贵，但是如果我们把所有的数据都去做了灾备，显然也是一种浪费。...所以，对数据有选择性的做备份，才是一名好架构师的表现。 第二个问题：要应对多大的灾难 这个问题的根本就是备份数量以及备份地点的选择。...之前提到过如果数据库已经是高可用的，那么这里面的数据确实已经具备了一定的灾难应对能力，但为什么说这样的灾备级别不够呢？因为通常在线业务的数据库集群都在一个机房，甚至一个机架。
应用可以部署一部分节点到第二个机房，数据库也可以将主备库交叉部署到不同的机房。 这一阶段，只是解决了机房容量不足的问题，两个机房逻辑上仍是一个整体。...异地灾备机房距离数据库主节点距离过远、访问耗时过长，异地备节点数据又不是强一致的，所以无法直接提供在线服务。...在扩展能力上，由于跨地区的备份中心不承载核心业务，不能解决核心业务跨地区扩展的问题；在成本上，灾备系统仅在容灾时使用，资源利用率低，成本较高；在容灾能力上，由于灾备系统冷备等待，容灾时可用性低，切换风险较大...但是按照当年双十一的业务指标做技术规划的时候，却碰到了一个棘手的问题：Oracle数据库的连接不够用了。 ? 虽然数据库是按用户维度水平拆分的，但是应用层流量是完全随机的。...前面讲的是正常情况下如何“多活”，机房故障情况下就要发挥单元之间的容灾互备作用了。 ? 一个城市整体故障的情况下，应用层流量通过规则的切换，由事先规划好的其他单元接管。
容灾目标： a. 三地五中心部署，数据中心级别容灾 b. 数据毫秒级实时异地同步备份，业务秒级异地主备切换 3. 性能目标： a. 自动线性扩容 b....4.1.1.5 系统容灾 金融系统对容灾有极高的要求。首先是数据需要支持同城和异地备份，确保数据有区域级灾备能力。再者需要支持业务的快速自动主备切换，时间就是金钱。...如果是同步备份，则主备机必须同时在线，任何一台出现问题都会导致业务中断。备机越多，当中任何一台出问题的概率越大，业务中断的概率也越大，因此同步备份的问题在于数据容灾能力越强，系统越不稳定。...图4.1（点击可查看大图） 我们创新性地采用了双层（核心业务层和基础架构层）一体的设计来实现业务的快速自动主备切换。当数据出现灾备切换时，定制化的Raft算法会同时切换数据和业务逻辑至灾备节点。...这个过程是一个经典的数据库回滚日志（WAL，Write Ahead Log）案例，也是账务系统的本地数据存储格式。由于单机机器故障可能会导致日志丢失，我们采用Raft强一致性算法来增强数据容灾能力。
简单描述一下这个事情，某服务商提供的数据库产品，产品的整体设计和架构是一流的，我是这样看的（一流的很多，不用瞎猜，凡是给我扣帽子说我说某某不好的，可以等着律师信。）这篇文字是对事不对人。...起因是这个服务商提供的数据库产品的升级部分，他在升级的时候一直是一种，我要升级并告知你了（具体你看得见与否，理解不理解和我无关），如果你不取消，我就强制直接升级的工作方法，我们一直和他们沟通，一般来说数据库产品的升级是不能这样的...我们以另外一个企业的一个数据库升级页面来看看其他的一些企业是如何做的，下面是一个企业在自己的服务页面上显示自己的一款数据库产品升级的时间表，以及升级的一些活动的内容。...3 考虑问题的维度少，并未从多个维度考虑升级的问题，如我和他们沟通的时候，他们认为某个升级是必须的，但是经过1分钟的沟通后，我就确认他们得升级和我们的数据库使用的功能没有任何关系，并且他们之前认为这个升级是严重的...这里是理解也知道大部分企业都必须走这样一条，“曲折” 的道路，但还是希望一个好的产品，能多注意一些细节，终究产品面对的客户也不都是低端的客户，一个世界级的产品，应该有世界级产品的考量。
在原型阶段，当时主流是 MySQL 5.6、5.7 才刚出来；对于高可用要求，行里的应用是要做到同城切换，上海两个园区要做到 RPO 是 0，RTO 非常小，同时异地北京有一个灾备中心，就是两地三中心。...我们把 1 主 2 备，本地 1 备和同城 1 备，扩展成 1 主 3 备，通过半同步的机制，做到真正的在系统级去保证 RPO=0。...②异地灾备和存储优化 异地灾备和存储方面，当初跑的太快，方方面面有些没有考虑那么完备。 刚才说了，我们在上海到北京有一个灾备。...数据灾备刚开始，方案采用磁盘复制实现灾备，这个也是要支出软件费用，也比较耗钱。 还有就是冷备，无法热切换，RTO 至少半个小时以上。这个方面我们改进了，用了 MySQL 异步复制。...我们通过 MySQL 支持的核心交易达到日均 7 亿的交易量，经历过双十一、2018 年的双十一和春节的高峰期的 1.5 万的 TPS。 我们的架构现在通过横向扩展可以达到几万的 TPS。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
