MySQL for PCF v2.2简介

READ

现代应用架构是分布式的,通常基于微服务。这种架构通过将功能分解为更小的松散耦合模块,在性能、扩展性、容错和资源共享方面获得了极大优势。

除了提供这些运行环境方面的优势之外,功能分解还让开发团队能够自主交付软件,而且工作节奏远远快于一体化软件。各团队可以按照自己的发布周期开展工作,让整体工作效率得到很大提升。

这种方法支持增量、快速地发布软件(正是“敏捷”方法的特性),降低了“一损俱损”的一体化方法中固有的故障风险。

为了实行这种方法,每个团队都需要完全控制自己的技术堆栈,以免堆栈产生跨团队的依赖关系。而对于数据层,微服务之间的隔离导致“每个微服务模式各有一个数据库”。其结果是专用的数据库泛滥,每个数据库都成为各自微服务的记录系统。

在分布式架构中,用户发起的一个请求会涉及若干微服务。一处故障会引发涟漪效应,一路传递开来,甚至影响多个路径。每多一个故障点,系统的整体可用性就会成倍下降,因此即便使用了高度可靠的组件,但多个组件组合起来的可靠性却会严重下降。

“对分布式架构友好”的应用在设计时会考虑故障,并寻找机制来克服这些可能的故障。对于MySQL,这要求该数据库在故障发生之后具备可用性和可恢复性。

MySQL for PCF v2.2实现了这一目标。使用它,运维人员无需具备精深的MySQL知识,即可提供主从模式的MySQL。这样一来,运维人员可以采用尽量减少平均恢复时间(MTTR)的做法,并关注满足其恢复点/时间目标的做法。MySQL for PCF v2.2 让运维人员可以通过多可用区(AZ)、主从方案满足应用的正常运行时间要求。

主从方案简介

MySQL Service Broker 将主从数据库部署到两个AZ的两个MySQL 虚拟机上。写入主数据库的所有数据都异步复制到从数据库。出现网络故障时,运维人员可以轻松地将从数据库提升,以恢复数据库可用性。

过去,管理多节点MySQL群集是一项困难工作。如果使用MySQL for PCF v2.2,运维人员可以依靠平台来监控和维护多个多节点群集。群集的标准编排工作将自动完成,因此数据库管理员可以得到解放,去关注其他任务。

灾难来袭,数据得到保护

业务要成功,业务数据必须随时可用而且正确无误。然而,各种事故时有发生。MySQL for PCF v2.2 确保你的数据即使面临事故,依然保持一致性,并得到快速恢复。

根据CAP定理,一个分布式系统不能同时获得一致性和可用性。大多数分布式系统使用 RAFT 或 PAXOS 等算法来确定群集状态。这些算法给这些系统带来了不必要的运维开销。其结果是,一旦发生问题,与没有这种开销的简单系统相比,这些复杂系统很难恢复。

借助MySQL for PCF v2.2,Pivotal创建了一个大规模的数据库,易于运维,即使发生最严重的事故也不成问题。这是因为这个数据库不依赖任何投票算法。如果一个MySQL虚拟机是在计划外的部署中重新创建的,它会返回只读模式。

MySQL for PCF v2.2的开发始终以Day 2工作为主要优先级。它提供了几个构建块,让主从实例的恢复变得简单易行。PCF运维人员无需学习新的工具,因为这些构建块都是大家已经熟悉的BOSH短作业。使用这些短作业,在发生意外的中断时,一个命令即可提升从数据库,恢复服务可用性。

业务连续性很关键

应用之下的基础架构发生故障(这肯定无法避免)时,必须确保关键业务数据具备恢复能力,因为如果这些数据丢失,应用提供功能和开展业务的能力会受到威胁。在不丢失大量数据的情况下恢复连接是关键,而这就是MySQL for PCF v2.2提供的功能。宕机和数据丢失带来的影响可能很难量化,但我们都知道,在如今严峻的业务环境中,由此产生的经济损失无法估量。从这个角度讲,我们绝不希望发生故障。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180322B068CX00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注腾讯云开发者

领取腾讯云代金券