爱可生洪斌：MySQL云数据库架构设计实践

【IT168评论】本文按照洪斌2018年5月12日在【第九届中国数据库手艺大会】上的演讲内容拾掇而成。

洪斌，MySQL手艺专家，现任爱可生手艺办事总监，担任MySQL数据库在保守行业客户的使用推广与手艺征询，曾为运营商、银行、证券、安全、航空等行业内数家大型企业供给MySQL手艺征询办事。

起首，我们先来回首一下MySQL的版本演进过程以及方才发布的MySQL 8。0的新特征。

MySQL是一个有20多年汗青的开源数据库，在整个互联网时代都长短常风行的数据库，MySQL版本的演进过程，大师能够参考上图。

不久之前，方才发布的MySQL 8。0有很是多的新特征，这里我会挑选比力主要的特征和大师分享。

第一，MySQL曾经成为了NoSQL+SQL的新架构。近几年，文档型数据库成长很火热，例如MongoDB，大师利用得也比力多，考虑到如许的营业场景，MySQL在5。7版本的时候就曾经支撑JSON数据类型，8。0版本对这种支撑做了更多的优化，并开放了X Protocol和谈用来支撑NoSQL接口。

这意味着MySQL在一个平台下，既有基于SQL的查询，也有基于NoSQL的API体例，而且插手了X Protocal和谈的支撑，能够操纵现有的API间接拜候MySQL。MySQL不断在吸纳开源社区提出的建议，努力于建筑一个更互联网化的数据库。

SQL支撑，良多人认为MySQL中的SQL长短常简单的，不克不及做复杂的查询，而另一个开源数据库——PostgreSQL则可以或许处置更多更复杂的查询。可是MySQL 8。0版本满足了大师如许的需求期望，其对SQL的支撑曾经与其他开源数据库，以至是一线贸易数据库持平，以至在某些方面可能做得更好，例如JSON。

上图列出了MySQL 8。0的良多新特征，这里就不逐个赘述了，感乐趣的小伙伴能够去官网查看文档。mysql

下面我们来讲讲DBaaS的架构演进以及我们的手艺选型。其实，大师都曾经感遭到了，良多NewSQL厂商或者是IT大厂都在基于开源数据库或NewSQL来做一些优化以满足本人的营业场景。

可是，我们的考虑是拥抱原厂，由于原厂版本是大师利用最多的，若何让保守企业或者是没有自研能力的客户也能够很好的利用它，这是第一点。其次，整个的运维成长曾经越来越成熟了，从手动到主动化再到自助化，我们但愿可以或许供给一种办事化的体例，在不上云的环境下也能够供给自助化的办事能力。mysql第三办事尺度化，把数据库办事做成一种尺度的办事，对营业来说，你不需要关怀架构，只需告诉我你要什么工具，平台来帮你处理问题。

2011年，我们做了第一代的设想，其时我们帮挪动研究院做了一个RDS。虽然说是叫RDS，但现实上就是把MySQL作为一种办事来面向挪动企业客户。第一代设想整个架构比力简单，包罗两个平面，一个是节制平面，由一个manager来担任接口挪用以及和agent的通信、指令下发。MySQL用来存元数据消息，DBA间接通过manager拜候功能模块。每个数据库办事器、数据库节点都有一个agent，agent托管MySQL办事。其时我们的manager、agent等等都是用Java开辟的。

第一代设想现实上仍是需要通过脚本，在此根本上，我们做了第二代两层布局的设想。我们把manage这一层做了拆分，拆分出一个接口面向IT办事，并作为安排层，下面仍然是agent，两头加了一个额外开辟的组件——Haserver，它是用来处理MySQL主从切换等等。可是它也有问题，就是只能处理一主一从的failover，当我们扩展了新的从机时，它是没法子操纵其它从机来做failover。

前面两种方案都是攒出来的架构，各类各样的组件攒在一路，开辟言语也纷歧样，这对我们的测试以及整个摆设长短常有局限性的。若是要在各类各样的客户情况摆设时，需要耗损很大的精神去做兼容性测试。

架构本身没有必然的扩展性，mysql这就意味着功能扩展要在本来的根本办事上面去点窜之前的模块代码。当环节组件挂了，整个系统都没法去响应，虽然当然不会影响下面的办事，可是可用性没有保障，元数据消息也没有保障。

failover没法包管数据分歧性，即便是在第二代架构，failover要想包管分歧姓也要依赖于存储。在5。6版本的时候，它是先提交了，然后发到备机上，比及响应之后才发给营业端。但现实上对于存储引擎这一层，早就曾经提交了，这时你切换过去，即便没有降级，也没法包管数据分歧性。

监控诉警之前在平台里是没有的，我们只做了整个的安排和办理，监控诉警要依赖于第三方。每一次数据库实例建立当前，还要对接新的监控系统。

备份打算依托按时使命，这对于大规模集群来说是很难去办理的，备份只是简单的将数据备下来了，可是数据能否恢复可用，没无机制来保障恢复的练习训练。

基于上述问题，我们对架构做了一次大的调整和革新。在设想第三代架构的时候，我们考量了以下方面：起首，在整个的开辟系统上，我们去更倾向于用Go言语来实现，由于Go言语更适合大规模的集群办理系统。

架构设想方面，我们把本来的架构的话做了微办事的拆分，一来是提高整个功能性的扩展，削减毛病，由于每个组件都是独立的，所以子组件毛病的话，也不会影响其它组件的一般运转；二来是逐级守护，我们把整个架构划分成了良多个层级，每一层级之间会来做可用性守护，通过自检报警或者反向告警的体例来提高整个集群的可用性。别的，在良多私有云情况中，好比OpenStack，会用VPC收集做租户的隔离，所以我们也要考虑支撑VPC收集。

平安性方面的考量次要有以下几点：第一，所有的链路之间做加密，RPC链路加密GRPC with TLS，每个办事器生成私钥；第二，日记无明文暗码，落地加密保留；第三，审计分歧，所有的操作流程都要有日记记实下来，便利后期的审计，此次要是办事于对监管要求很高的行业；第四，Linux capabilities机制权限细分，良多客户可能不会答应利用root和sudo，那么碰到需要高权限来做的工作怎样办？我们能够操纵系统自带的机制给法式本身加一些需要的权限。

上图是我们第三代设想的架构图，这此中我们添加了一个平面——两头件。节制平面，我们把良多功能拆成了组件。ucore用来做设置装备摆设办理的，本来MySQL是一个单点，你要处理高可用问题，必需挂一个工具来冗余，而ucore自带高可用和谈，通过选举Leader的架构来存储整个集群的设置装备摆设办理消息，所有组件城市从这里来拉取本人的消息。

UMC是面向于DBA的，是DBA办理整个平台的一个入口，所有的全局办理操作都是通过UMC进入的。

URDS是面向于开辟者供给自办事的，所有的自助化申请、主动化办理都能够通过平台去申请并办理集群。

Urman-mgr是担任整个集群的备份安排和办理。下面数据库实例的整个备份安排都是通过Urman-mgr办事去节制，相对应的agent接管Urman-mgr发来的指令和请求并施行。

umonitor用来做监控，并对监控的趋向做展现，它对应的是ustat，ustat担任机能数据的采集，包罗我们所守护的办事以及系统层面资本的监控。

Uguard-mag是担任整个集群办事可用性的守护， uguard去做决策切换、决策下发等等，uguard-agent担任对决策的施行。

数据平面，若是是物理级，我们会在上面摆设多个MySQL实例，实例间利用Cgroup的体例做资本隔离，好比对以及磁盘IO做隔离，办理员能够设定隔离规格。别的，我们也能够用磁盘配额的体例对磁盘空间进行配额办理。

最上面，我们供给了两个Proxy。uproxy次要处理一些读写分手的场景，它是一个通明的读写分手两头件，所谓通明就是营业无需对两头件做任何操作，只需利用账号暗码去拜候就能够了。这个两头件是我们利用C++自主研发的。

ushard处理程度扩展。 MySQL读写分手、程度扩展曾经有良多成熟的架构了，我们更倾向于若何做数据分片、数据路由以及SQL解析。在这个层面，我们也会去守护可用性，摆设多个两头件节点，然后有办事来守护，让整个集群看起来没有单点风险。

上图是我们常用的一些架构，最简单的是一主一从，并做一些failover高可用；中型系统中读的比例可能会比力大，我们需要去做横向扩展，添加从机来做读写分手，若是营业不情愿做的话，能够操纵两头件来做读写分手；再大型的系统中就需要做程度分片，每个分片都是一个小的高可用集群。

我们的方针是把这几种架构都集中在一个平台里办理，而不是每个架构去成立本人的办理系统。

办事可用性，我们通过几个维度来引见。起首，之前我们看到的、做的可能更多的是MySQL怎样切换，现实上MySQL切换只是高可用里的一个环节，并不是所有，我们需要保障整个集群的可用性，例如从机的可用性、统计数据的分歧性等等。

第三，Slave也要有一些守护监控，呈现问题时能够把它拉起来，但若是拉起的次数太多的话，就要告警了。

第四，复制链路的可用性。复制链路出毛病的话，切换时可能两头有段时间的工具没复制过去。

最初，决策者的可用性。只要以上所有的可用性都获得保障，才能确保整个集群的可用性是不变的。

以MySQL的切换为例，它有N多个步调。起首，Old Master就代表原主，New Master代表新主，Proxy是可选的，取决于我们有没有用两头件去做读写分手。

第一步是办事检测，不断地去检测办事器，若是办事挂了之后，不会顿时切换，我们会测验考试去做拉取，看看能不克不及启动起来，若是可以或许启动起来，那我们认为是没有问题的，可是若是短时间内多次宕机，那我们就认为是不不变的，需要去做一些切换。

切换时要先解绑SIP，SIP是办事的入口，遏制当前事务，然后把流量入口全数堵截，踢出集群，防止第二次持续的切换。从候选Slave选择从机提拔成为新的主机，并进行一些需要的数据弥补，断根复制关系，封闭read-only，再绑定到新的SIP，广播ARP。这时，若是你有流量入口的话，间接开启流量入口。

办事可用性的逐层守护，最外层是办事层，真正的数据库办事，我们此刻支撑了MySQL和MongoDB，那么下一步的打算可能会是Redis的支撑。然后接下来是各类功能组件客户端的办事，客户端来守护方针办事，而客户端的可用性由它的办理端来守护。最焦点的是ucore，它是一个分布式的小集群，守护下面托管的每一层的办理节点。办理节点没有利用分布式集群，而是利用了主备架构，主挂了当前，ucore把备节点提拔为主节点去顶替工作。

别的，我们还引入了SLA，这不是我们凡是定义的SLA，它是一个辅助切换决策的量化机制。我们有两种和谈，一个是RPO和谈，一个是RTO和谈。RPO和谈现实上保障的是数据有没有丢失，签定一个和谈告诉法式能否答应数据丢失。RPO强调的是对数据分歧性的容忍度，其分为两大级别，别离是P级别和PE级别。P级别针对的是没有差别的场景，PE级别针对的是主从之间有差别的场景，例如数据没有传过来到底是由于收集延迟仍是有毛病发生。

RTO关心的是营业持续性，同样也分为T和TE两个级别。例如，日记系统我当然是但愿可以或许保留更多的日记，但你若是跨越十分钟，日记还没有重画完，那么在某些场景下，我答应丢一些数据来包管办事的可用性。这些级此外门槛都能够由办理员来自定义。

数据可用性包罗了两部门，一部门是备份，一部门是练习训练。备份，由manager节制整个集群的备份策略、备份使命的下发以及备份使命的编排。使命下发给agent施行，施行完之后，若是有离线转储的机制就主动转储，没有就在当地保留。

做完整份之后，我们还需要有一个按期的练习训练，在平台中通过设定的练习训练使命来恢复数据；备份练习训练的使命编排，若是我们是设定一个时间，所有实例都在此时做练习训练，那么如果一台机械上有良多实例的话，资本耗损会很大。所以我们是选择设定一个时间窗口，然后将备份使命错开时间施行，同时记实备份破费的时间，便利下次更好的编排使命。

关于监控设想我们之前也考虑了良多方案，最终选择了基于prometheus的监控框架，再加上Grafana来做展示、存储和查询。prometheus原厂更多地是单用，每一个办事对应一个采集历程往来来往采集办事，但若是一台办事器上挂多个MySQL的话，那么办理起来会出格麻烦。所以，我们做了单个的export，export去监控整个集群里所有的方针办事，方针办事建立当前，主动发觉办事，并将数据及时的采集到监控核心存储。数据量大了当前，还能够对数据集进行分片分区的架构革新，同时我们还会做高机能数据采集，并行采集所有办事数据。

在整个集群中，除了根基的运维办理，还需要无数据传输办事，DTS就是次要来处理雷同数据迁徙的场景，它的设想有以下几个要点：

起首是一个分布式架构，不克不及有单点；在做云之间的数据迁徙时，两头跨互联网的带宽可能不太大，所以我们将窄宽带下的传输效率优化得比原生还要好；支撑全量+增量的传输体例；支撑GTIB和并行回放；在输出端支撑Kafka两头件动静队列，能够对接下流的大数据平台；兼容支流的云厂商产物，阿里云、微软云和原生MySQL。

上图是DTS架构的设想图，分为两层。Manager是通过leader+follower的体例去做高可用，若是leader挂了的话，备节点会从头选主，并将数据源数据保留到KV存储里，它们之间通过SLA来通信。Agent既能够作为数据的提取端，也能够作为数据的回放端，通过提取端从MySQL的binlog傍边提取日记消息，然后传送给回放端，回放端并行回放日记。manager担任整个集群的使命安排，并把使命分派给agent，如许的话一个集群能够办理多套数据库办事。