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提供的功能。宕机和数据丢失带来的影响可能很难量化，但我们都知道，在如今严峻的业务环境中，由此产生的经济损失无法估量。从这个角度讲，我们绝不希望发生故障。