业务的不断演进，系统的数据量不断扩大，技术栈越来越复杂，系统模块越来越多，造成信息系统中断的事件的风险场景越来越多，中断事件的频率和种类持续增长，且有相当一部份事件会造成业务中断，可用性问题越来越严峻。一个严重的业务可用性问题通常是多个层面上的可用性保障均失效的结果，比如：架构的高可用能力，监控能力、自动化工具能力、应急能力等，所以说运维组织的事件管理能力特别的重要，应该本着“不浪费故障”的理念去深挖故障背后的问题，不断的完善每个环节的不足（当然，这里不提倡追责的方式分析故障）。可以用“海恩法则”来进一步解释可用性问题由量变向质变转变的过程：海恩法则：一起重大的飞行安全事故背后都会有29个事故征兆，每个征兆背后又有300个事故苗头，每个苗头背后还有1000个事故隐患。由此可见，对隐患、苗头、征兆的忽略，是导致意想不到的安全事故发生的罪魁祸首。《百度百科》
MySQL 主备切换（Master-Slave Switching）是指在 MySQL 主从复制架构中，将从库（Slave）提升为主库（Master），原主库降为从库的过程。这种切换通常用于故障恢复、负载均衡、系统升级等场景。腾讯云混沌演练平台可对云 MySQL 进行主备切换故障注入，通过混沌实验帮助构建高韧性的系统。
也许很多企业很幸运，从来没有经历过数据丢失。但是，一旦发生企业关键数据的丢失，就会很大程度上影响业务发展，同时造成严重经济损失。
出于业务连续性与数据保护等目的，最早是银行等金融机构完成了业务的容灾系统的建设，随后电力等关键能源行业、海关等政务单位、大型互联网公司都着手建设了完备的业务容灾系统。
如今是数据驱动时代，数据库作为企业的核心资产之一，其安全性和稳定性显得尤为重要。然而，面对复杂多变的业务场景和不断演变的技术挑战，如何把握现有数据库架构可承受故障的故障级别、发生故障后的高可用性方案是否有效，成为了许多数据库用户关注的焦点，也是腾讯云MySQL在服务众多重保用户时思考的问题。
本次VMware vForum大会（北京站和上海站），有幸和同事Alex You一起分享了《如何基于虚拟化构建双活数据中心》课题。我主要负责介绍了VMware灾备与双活方案。很多同学表示出来了较大的兴趣，因此写出来共享给大家，由于内容较多，本次先发布灾备部分内容。 一.灾备 谈到灾备，首先谈到灾害。在过去几年中，全球各国经历过许多大范围的灾难，如海啸，地震等。这些是我们从新闻上得知的比较重大的示例，但同时还存在很多范围较小的中断示例，如数据中心断电、数据中心网络中断、主机故障等。行业研究显示，那些经历大
机房搬迁，肯定是要把机房里面运行的所有设备，包括交换路由、防火墙、服务器这些从老的机房下架，再把它们安装的新的机房里面。在设备搬运途中，设备肯定是要断电的。但如果有工程师对客户说，在搬机房的过程中能做到网络不中断，你信不信？
资讯系统应用已深深影响人类的生活，因应地球暖化议题政府提倡节能减碳、组织改造、机房共构，以减少政府的资源浪费并提升组织效率。网路的连结企业面对全世界的竞争，企业要提升企业获利，则必须提供多元化的资讯系统服务以增加客户杂化服务满意度，增加客户的回购率，进而提供企业获利。相反的服务越多则资讯系统的软/硬体设备数量就越多，电力的消耗、技术能力的门槛、空间的佔用就越多，硬体设备环境改变由Rack伺服器变成刀锋伺服器，但系统及资料的保护依旧无法改善，仍然是资讯主管的一点重大问题，因此异地备援系统、资料异地存放等方式产
我们常说的应急演练，通常是先出一个异常事件场景，提前做好参与方的准备工作，按应急预案指挥整个演练过程，IT内多个团队、业务、供应商分工协作，形成整体联动，实现了从问题发现到启动应急响应机制，到故障诊断，现场应急恢复。通过演练过程，检验应急预案是否有效，可用性架构是否可靠，应急处置过程中判断是否准确果断，处理及时有效，内部分工明确，应急操作是否规范等，最终评价演练是否达到预期效果。
2022年5月24日，吉林省农村信用社联合社发布《2022年核心主机及配套存储等设备采购项目》竞争性谈判公告 预算金额：8688 万元 采购需求： 1、硬件设备共计31台： 其中核心主机3台、核心主机硬件控制台4台、核心高端存储3台、光纤交换机16台、存储虚拟化网关3套、磁带库2台（含6个驱动器升级） 2、核心主机使用的配套软件3套： 其中核心主机存储切换管理软件1套，核心系统性能分析软件1套，核心系统开发工具1套 3、原厂集成实施服务： 包括核心系统生产及同城灾备三点架构环境搭建，核心业务系统数据平滑迁移
灾备系统建设是IT领域永恒的话题，但是，目前很多企业仍未重视灾备建设的重要性。不少企业的数据基本是裸奔状态。有些人认为存储或者服务器上做了RAID就万无一失了，这是被严重误导了，RAID只能防止单盘故障时数据不丢，是为了应对硬盘错误，其目的不是备份，其无法防止由于病毒感染、误删除、环境灾难导致的数据丢失。而另一小部分人则是压根没想着去保护数据。不少企业都是在经历过数据丢失导致的一系列损失之后才痛定思痛的。
随着企业对数据处理和存储需求的不断增长，Redis作为一款高性能的内存数据结构存储系统，已成为业界的首选。然而，在Redis中的使用中，会面对一些潜在的故障风险，其中主节点故障，发生主从切换最为常见。
灾备，是企业中一项重要的技术应用，对于企业数据安全起到了很大的作用。 一般来说，灾备的级别可以分为数据级、应用级和业务级三个级别。
主备、冷备、热备、双活、多活、同城、异地、多云，等等等等，这些保证业务高可用和容灾名词，我们经常会听到，不绝于耳。
可用性是一个可以量化的指标，计算的公式在维基百科中是这样描述的：根据系统损害、无法使用的时间，以及由无法运作恢复到可运作状况的时间，与系统总运作时间的比较。行业内一般用几个9表示可用性指标，对应用的可用性程度一般衡量标准有三个9到五个9；一般我们的系统至少要到 4 个 9（99.99%）的可用性才能谈得上高可用。
乐元素是国内休闲益智游戏领域领航企业。为了给用户提供更稳定可靠的使用体验，在2023年Q2开始，乐元素运维、业务团队联合腾讯云售后专家和技术专家，基于针对乐元素旗下休闲游戏产品《开心消消乐》展开同城双活改造项目，目的是了解并改善业务容灾部署状况，进一步强化云上业务系统的容灾能力。
添加灾备预案：不仅能做Oracle的灾备切换，OA、ERP等应用也能做哦！还能设置不同灾难场景下的预案呢。
郜德光，携程技术保障中心高级数据库经理，负责数据库相关的运维工作，参与了SQL Server和MySQL的高可用以及数据库容灾建设。喜欢钻研技术，对数据相关的技术一直保持着浓厚的兴趣。
8月23日，周五，到了下班时间，赣州银行数据中心还是一片忙碌。今天晚上，他们将在这里开始一年一度的灾备切换演练，11个部室和8个分支行验证机构参与，演练范围包括核心业务系统、柜面系统、二代支付系统等23个重要业务系统和核心骨干网络。
将异地备份的频度提升为实时备份，且需要制定数据的备份策略和恢复策略、备份程序和恢复程序等。
为了给客户提供更优质、更可靠的服务，金蝶业务团队从2022年开始，就已经在腾讯云售后专家的协助下，陆续对业务系统完成双活改造。改造完成后，业务团队通过腾讯云混沌演练平台进行故障注入，以检验业务系统的容灾效果，从而提升业务系统韧性。本次演练主要针对金蝶小微业务线（精斗云&KIS云），涉及10大业务故障场景，是财务、新零售、电商等领域行业提高系统可用性的一次最佳实践。
在云网融合大数据时代，数据已经成为重要的生产要素。特别是棱镜门、永恒之蓝、汶川大地震这类造成大规模数据丢失和泄漏的人为或自然灾害事件发生后，中国相继出台了一系列的法律法规，对各组织机构的数据安全保护条件进行限定，如 2016 年颁布的《中华人民共和国网络安全法》、 2021 年全国人民代表大会通过的《数据安全法》等。
1. 选择实例规格根据业务需求,选择合适的实例规格,比如计算优化型或者高IO型的云服务器:
当检测到物理线路1发生故障，系统自动将流量切换至物理线路2，保证业务正常运行。故障修复后，流量自动切回。
时至今日，企业运作和业务运营对于IT系统的依赖性越来越高，对于IT系统的稳定性和可靠性的要求也越来越高。然而，＂天有不测风云，人有旦夕祸福＂，一旦IT系统因为天灾或人为因素等等意外事故导致系统毁坏而长期无法运行，将造成整个企业在营运上的重大损失。曾几何时支付宝、携程等互联网企业由于IT系统技术故障而相继“瘫痪”，更是从反面说明了容灾系统建设的重要性。
腾讯云数据库国产数据库专题线上技术沙龙已圆满结束，本期带来毕汉斌分享的《从0到1搭建一个高可用的TDSQL集群》直播视频和文字回顾。 关注“腾讯云数据库”公众号，回复“0331毕汉斌”，即可下载直播分享PPT。 1 前言 为帮助开发者更好地了解和学习分布式数据库技术，2020年3月-5月，腾讯云数据库、云加社区联合腾讯TEG数据库工作组特推出国产数据库专题线上技术沙龙，邀请数十位鹅厂资深数据库专家在线深入解读TDSQL、CDB/CynosDB、TBase三款鹅厂自研数据库的核心架构、技术实现原理和最佳实践
越来越多的企业在数字化转型和上云进程中选择混合云的形态（云+自建 IDC 或云+其他厂商云）来进行容灾建设，一方面不会过度依赖单一云厂商，另一方面还能充分利用已有的线下 IDC 资源。
业务容灾是所有容灾中最复杂的一种场景，涉及到业务应用、中间件、数据库及底层的计算、存储、网络等资源。就云上业务容灾来讲整个容灾覆盖到IaaS、PaaS、SaaS层。在容灾方案确认并且实施落地之后，就需要进行容灾切换演练工作。下面主要介绍下容灾切换演练的流程及具体操作细节。
产品容灾主要就是将云产品做跨可用区或者跨地域部署，实现多地部署，如果某一个地域出现了问题的时候，可以进行自动切换，确保整体可用。
容灾半径是衡量容灾方案所能承受的灾难影响范围的指标。不同灾难的影响范围是不同的，而距离也会影响到容灾技术的选择。容灾中心的架构按照源备端之间的距离，可分为本地容灾、同城双活、两地三中心。
今天看到有一个网友提了一个问题，描述很简短 测试DG时，主库不能宕机，如何测试failover? 其实这个需求从业务层面来说是合理的，一个数据量很大的核心数据库，如果需要做灾难演练，就
针对Oracle迁移上云项目，云提供给用户的物理机上加载有三张网卡供用户使用，一张用于跑业务，另外两张可以用于心跳线网络。另外，存储网络是单独的网口，在建设时已由服务商做好配置，不含在这三张网卡内。基于公有云技术，为了组建资源池内部管理控制专网，因此现市面上公有云提供商的IPMI端口，均不能提供出来用于对外访问。
近年来随着数字化转型的不断深入，银行电子化程度逐步提升，线上金融场景的落地推广对金融机构的业务连续性提出了更为严苛的要求。
本文介绍linux服务器安装keepalive服务，结合腾讯云的HAVIP（高可用虚拟IP）配置云服务器主备实验
不论是自然灾难还是人为灾难，只要有数据传输、存储和交换的地方，就会产生数据失效、丢失、损坏等风险，一旦发生，就会给数据中心带来难以估计的损失；而灾备，是一种对业务数据安全的重要保护方式。
在分布式系统中不可避免的会遇到网络故障，机器宕机，磁盘损坏等问题，为了向用户不中断且正确的提供服务，要求系统有一定的冗余与容错能力。RocketMQ 在日志，统计分析，在线交易，金融交易等丰富的生产场景中发挥着至关重要的作用，而不同环境对基础设施的成本与可靠性提出了不同的诉求。在 RocketMQ v4 版本中有两种主流高可用设计，分别是主备模式的无切换架构和基于 Raft 的多副本架构（图中左侧和右侧所示）。生产实践中我们发现，两副本的冷备模式下备节点资源利用率低，主宕机时特殊类型消息存在可用性问题；而 Raft 高度串行化，基于多数派的确认机制在扩展只读副本时不够灵活，无法很好的支持两机房对等部署，异地多中心等复杂场景。RocketMQ v5 版本融合了上述方案的优势，提出 DLedger Controller 作为管控节点（中间部分所示），将选举逻辑插件化并优化了数据复制的实现。
阅文集团是一家以数字阅读为基础，IP培育与开发为核心的综合性文化产业集团。集团汇聚了强大的创作者阵营、丰富的作品储备，覆盖200多种内容品类，触达数亿用户，已成功输出《斗罗大陆》《斗破苍穹》《鬼吹灯》《盗墓笔记》《琅琊榜》《庆余年》等网文IP改编的动漫、影视、游戏等多业态产品。
双机热备就是使用互为备份的两台服务器共同执行同一服务，其中一台主机为工作机（Primary Server），另一台主机为备份机（Standby Server），保证系统不间断的运行。双机热备软件就是实现上述功能的软件产品。双机热备针对的是服务器的临时故障所做的一种备份技术，通过双机热备，来避免长时间的服务中断，保证系统长期、可靠的服务。
本文整理自美团技术沙龙第75期的主题分享《美团数据库攻防演练建设实践》，系超大规模数据库集群保稳系列（内含4个议题的PPT及视频）的第3篇文章。
使用的资源： nginx主服务器一台，nginx备服务器一台，使用keepalived进行宕机切换。 tomcat服务器两台，由nginx进行反向代理和负载均衡，此处可搭建服务器集群。 redis服务器一台，用于session的分离共享。 nginx主服务器：192.168.50.133 nginx备服务器：192.168.50.135 tomcat项目服务器1:192.168.50.137 tomcat项目服务器2:192.168.50.139 redis服务器：192.168.50.140 注意访问时需
客户的一套生产环境采用的架构是Oracle ADG + Keepalived，近期需要进行切换演练，要求我这边保障。ADG本身切换倒没啥可说的，但引入keepalived软件，就需要提前研究下这个架构。其实看了下环境配置，整体思路也非常简单，说白了就是利用keepalived软件引入一个VIP，应用侧只需配置连接这个VIP即可。 依据当前生产环境架构模拟了一套自己的测试环境。
数据库选型一直是困扰客户的难题，不仅要考虑底层的数据库技术，还需要结合企业业务特点、企业未来规划做决策。如何快速掌握数据库选型秘诀呢？答案无疑是看市场怎么做，看市场的同行是如何选择的。 近期，腾讯云数据库TDSQL助力福建海峡银行新一代核心业务系统正式上线（点击查看详情），为城商行提供核心改造解决方案。新核心关键业务系统采用“微服务+分布式”架构，改造历时14个月，依托腾讯云企业级分布式数据库TDSQL良好的兼容性、成熟的迁移能力和技术服务支持，海峡银行快速完成了核心系统的国产数据库替换，并基于腾讯云数据库
数据库是企业核心业务运行的重要组成部分，数据是企业的生命线，如果数据库出现宕机、数据丢失或不可用等问题，将会对企业的生产、营销和决策产生难以预估的影响，因此，一套高可用的数据库架构对于企业来说至关重要，可以最大化保证业务稳定性和数据可靠性。腾讯云MySQL推出全场景高可用性架构（All-Scenario High Availability Architecture，AS-HAA），用户可根据实际业务需求、业务类型自行配置。
👉腾小云导读 在系统的开发过程中，很多开发者都为了实现系统的高可用性而发愁。本文从研发规范层面、应用服务层面、存储层面、产品层面、运维部署层面、异常应急层面这六大层面去剖析一个高可用系统的架构设计需要有哪些关键的设计和考虑。希望腾讯的经验方法，能够给广大开发者提供参考。内容较长，您可以收藏后持续阅读。 👉看目录点收藏，随时涨技术 1 高可用系统的架构设计思想 1.1 可用性和高可用概念 1.2 高可用系统设计思想 2 研发规范层面 2.1 方案设计和编码规范 2.2 容量规划
一套完善的IT运维体系，仅依靠硬件设备的不断升级是远远不够的，事实上，IT系统运维是整个业务系统管理策略与方法的载体，是把管理思路转化为具体执行过程的媒介，因此，在新业务模式下，IT系统运维需要满足多层次的需求。
中间件稳定性尤为重要，本文希望梳理从各个方面形成一个体系回答这个问题。推而广之，其他技术治理也类似。本文主要内容有：
业务数据备份采用热备方式，容灾指标RPO接近“零”；但是RTO指标还是依赖于业务部署测试自动化能力。业务会进一步需要，在数据热备技术架构下，在成本可控的情况下，是否能进一步提升RTO指标呢？ 本文结合云平台的能力，来进一步讨论这个话题。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
