技术开发 频道

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

  【IT168 评论】本文根据洪斌2018年5月12日在【第九届中国数据库技术大会】上的演讲内容整理而成。

  讲师介绍:

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

  洪斌,MySQL技术专家,现任爱可生技术服务总监,负责MySQL数据库在传统行业客户的应用推广与技术咨询,曾为运营商、银行、证券、保险、航空等行业内数家大型企业提供MySQL技术咨询服务。

  分享大纲:

  ·MySQL 8.0

  ·为什么需要DBaaS

  ·架构设计演进

  ·服务可用性设计

  ·数据可用性设计

  ·监控设计

  ·DTS设计

  ·未来规划

  正文演讲:

  一.MySQL 8.0

  首先,我们先来回顾一下MySQL的版本演进过程以及刚刚发布的MySQL 8.0的新特性。

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

  MySQL是一个有20多年历史的开源数据库,在整个互联网时代都是非常流行的数据库,MySQL版本的演进过程,大家可以参考上图。

爱可生洪斌: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一直在吸纳开源社区提出的建议,致力于建造一个更互联网化的数据库。

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

  SQL支持,很多人认为MySQL中的SQL是非常简单的,不能做复杂的查询,而另一个开源数据库——PostgreSQL则能够处理更多更复杂的查询。但是MySQL 8.0版本满足了大家这样的需求期望,其对SQL的支持已经与其他开源数据库,甚至是一线商业数据库持平,甚至在某些方面可能做得更好,例如JSON。

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

  上图列出了MySQL 8.0的很多新特性,这里就不一一赘述了,感兴趣的小伙伴可以去官网查看文档。

  二.为什么需要DBaaS

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

  下面我们来讲讲DBaaS的架构演进以及我们的技术选型。其实,大家都已经感受到了,很多NewSQL厂商或者是IT大厂都在基于开源数据库或NewSQL来做一些优化以满足自己的业务场景。

  但是,我们的考虑是拥抱原厂,因为原厂版本是大家使用最多的,如何让传统企业或者是没有自研能力的客户也可以很好的使用它,这是第一点。其次,整个的运维发展已经越来越成熟了,从手动到自动化再到自助化,我们希望能够提供一种服务化的方式,在不上云的情况下也可以提供自助化的服务能力。第三服务标准化,把数据库服务做成一种标准的服务,对业务来说,你不需要关心架构,只要告诉我你要什么东西,平台来帮你解决问题。

  三.架构设计演进

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

  2011年,我们做了第一代的设计,当时我们帮移动研究院做了一个RDS。虽然说是叫RDS,但实际上就是把MySQL作为一种服务来面向移动企业客户。第一代设计整个架构比较简单,包括两个平面,一个是控制平面,由一个manager来负责接口调用以及和agent的通讯、指令下发。MySQL用来存元数据信息,DBA直接通过manager访问功能模块。每个数据库服务器、数据库节点都有一个agent,agent托管MySQL服务。当时我们的manager、agent等等都是用Java开发的。

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

  第一代设计实际上还是需要通过脚本,在此基础上,我们做了第二代两层结构的设计。我们把manage这一层做了拆分,拆分出一个接口面向IT服务,并作为调度层,下面仍然是agent,中间加了一个额外开发的组件——Haserver,它是用来解决MySQL主从切换等等。但是它也有问题,就是只能解决一主一从的failover,当我们扩展了新的从机时,它是没办法利用其它从机来做failover。

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

  前面两种方案都是攒出来的架构,各种各样的组件攒在一起,开发语言也不一样,这对我们的测试以及整个部署是非常有局限性的。如果要在各种各样的客户环境部署时,需要消耗很大的精力去做兼容性测试。

  架构本身没有一定的扩展性,这就意味着功能扩展要在原来的基础服务上面去修改之前的模块代码。当关键组件挂了,整个系统都没法去响应,虽然当然不会影响下面的服务,但是可用性没有保障,元数据信息也没有保障。

  failover没法保证数据一致性,即使是在第二代架构,failover要想保证一致姓也要依赖于存储。在5.6版本的时候,它是先提交了,然后发到备机上,等到响应之后才发给业务端。但实际上对于存储引擎这一层,早就已经提交了,这时你切换过去,即便没有降级,也没法保证数据一致性。

  监控告警之前在平台里是没有的,我们只做了整个的调度和管理,监控告警要依赖于第三方。每一次数据库实例创建以后,还要对接新的监控系统。

  备份计划依靠定时任务,这对于大规模集群来说是很难去管理的,备份只是简单的将数据备下来了,但是数据是否恢复可用,没有机制来保障恢复的演练。

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

  基于上述问题,我们对架构做了一次大的调整和改造。在设计第三代架构的时候,我们考量了以下方面:首先,在整个的开发体系上,我们去更倾向于用Go语言来实现,因为Go语言更适合大规模的集群管理系统。

  架构设计方面,我们把原来的架构的话做了微服务的拆分,一来是提高整个功能性的扩展,减少故障,因为每个组件都是独立的,所以子组件故障的话,也不会影响其它组件的正常运行;二来是逐级守护,我们把整个架构划分成了很多个层级,每一层级之间会来做可用性守护,通过自检报警或者反向告警的方式来提高整个集群的可用性。另外,在很多私有云环境中,比如OpenStack,会用VPC网络做租户的隔离,所以我们也要考虑支持VPC网络。

  安全性方面的考量主要有以下几点:第一,所有的链路之间做加密,RPC链路加密GRPC with TLS,每个服务器生成私钥;第二,日志无明文密码,落地加密保存;第三,审计一致,所有的操作流程都要有日志记录下来,方便后期的审计,这主要是服务于对监管要求很高的行业;第四,Linux capabilities机制权限细分,很多客户可能不会允许使用root和sudo,那么遇到需要高权限来做的事情怎么办?我们可以利用系统自带的机制给程序本身加一些必要的权限。

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

  上图是我们第三代设计的架构图,这其中我们增加了一个平面——中间件。控制平面,我们把很多功能拆成了组件。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的方式做资源隔离,比如对CPU内存以及磁盘IO做隔离,管理员可以设定隔离规格。另外,我们也可以用磁盘配额的方式对磁盘空间进行配额管理。

  最上面,我们提供了两个Proxy。uproxy主要解决一些读写分离的场景,它是一个透明的读写分离中间件,所谓透明就是业务无需对中间件做任何操作,只要使用账号密码去访问就可以了。这个中间件是我们使用C++自主研发的。

  ushard解决水平扩展。 MySQL读写分离、水平扩展已经有很多成熟的架构了,我们更倾向于如何做数据分片、数据路由以及SQL解析。在这个层面,我们也会去守护可用性,部署多个中间件节点,然后有服务来守护,让整个集群看起来没有单点风险。

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

  上图是我们常用的一些架构,最简单的是一主一从,并做一些failover高可用;中型系统中读的比例可能会比较大,我们需要去做横向扩展,增加从机来做读写分离,如果业务不愿意做的话,可以利用中间件来做读写分离;再大型的系统中就需要做水平分片,每个分片都是一个小的高可用集群。

  我们的目标是把这几种架构都集中在一个平台里管理,而不是每个架构去建立自己的管理体系。

  四.服务可用性设计

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

  服务可用性,我们通过几个维度来介绍。首先,之前我们看到的、做的可能更多的是MySQL怎么切换,实际上MySQL切换只是高可用里的一个环节,并不是所有,我们需要保障整个集群的可用性,例如从机的可用性、统计数据的一致性等等。

  其次,当主机挂了以后,failover从机时要确保从机不能写数据;

  第三,Slave也要有一些守护监控,出现问题时可以把它拉起来,但如果拉起的次数太多的话,就要告警了。

  第四,复制链路的可用性。复制链路出故障的话,切换时可能中间有段时间的东西没复制过去。

  最后,决策者的可用性。只有以上所有的可用性都得到保障,才能确保整个集群的可用性是稳定的。

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

  以MySQL的切换为例,它有N多个步骤。首先,Old Master就代表原主,New Master代表新主,Proxy是可选的,取决于我们有没有用中间件去做读写分离。

  第一步是服务检测,不停地去检测服务器,如果服务挂了之后,不会马上切换,我们会尝试去做拉取,看看能不能启动起来,如果能够启动起来,那我们认为是没有问题的,但是如果短时间内多次宕机,那我们就认为是不稳定的,需要去做一些切换。

  切换时要先解绑SIP,SIP是服务的入口,停止当前事务, 然后把流量入口全部切断,踢出集群,防止第二次连续的切换。从候选Slave选择从机提升成为新的主机,并进行一些必要的数据补偿,清除复制关系,关闭read-only,再绑定到新的SIP,广播ARP。这时,如果你有流量入口的话,直接开启流量入口。

  这样就完成了一次完整的failover。

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

  服务可用性的逐层守护,最外层是服务层,真正的数据库服务,我们现在支持了MySQL和MongoDB,那么下一步的计划可能会是Redis的支持。然后接下来是各种功能组件客户端的服务,客户端来守护目标服务,而客户端的可用性由它的管理端来守护。最核心的是ucore,它是一个分布式的小集群,守护下面托管的每一层的管理节点。管理节点没有使用分布式集群,而是使用了主备架构,主挂了以后,ucore把备节点提升为主节点去顶替工作。

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

  另外,我们还引入了SLA,这不是我们通常定义的SLA,它是一个辅助切换决策的量化机制。我们有两种协议,一个是RPO协议,一个是RTO协议。RPO协议实际上保障的是数据有没有丢失,签订一个协议告诉程序是否允许数据丢失。RPO强调的是对数据一致性的容忍度,其分为两大级别,分别是P级别和PE级别。P级别针对的是没有差异的场景,PE级别针对的是主从之间有差异的场景,例如数据没有传过来到底是因为网络延迟还是有故障发生。

  RTO关注的是业务连续性,同样也分为T和TE两个级别。例如,日志系统我当然是希望能够保留更多的日志,但你如果超过十分钟,日志还没有重画完,那么在某些场景下,我允许丢一些数据来保证服务的可用性。这些级别的门槛都可以由管理员来自定义。

  五.数据可用性设计

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

  数据可用性包括了两部分,一部分是备份,一部分是演练。备份,由manager控制整个集群的备份策略、备份任务的下发以及备份任务的编排。任务下发给agent执行,执行完之后,如果有离线转储的机制就自动转储,没有就在本地保存。

  做完备份之后,我们还需要有一个定期的演练,在平台中通过设定的演练任务来恢复数据;备份演练的任务编排,如果我们是设定一个时间,所有实例都在此时做演练,那么要是一台机器上有很多实例的话,资源消耗会很大。所以我们是选择设定一个时间窗口,然后将备份任务错开时间执行,同时记录备份花费的时间,方便下次更好的编排任务。

  六.监控设计

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

  关于监控设计我们之前也考虑了很多方案,最终选择了基于prometheus的监控框架,再加上Grafana来做展现、存储和查询。prometheus原厂更多地是单用,每一个服务对应一个采集进程来去采集服务,但如果一台服务器上挂多个MySQL的话,那么管理起来会特别麻烦。所以,我们做了单个的export,export去监控整个集群里所有的目标服务,目标服务创建以后,自动发现服务,并将数据实时的采集到监控中心存储。数据量大了以后,还可以对数据集进行分片分区的架构改造,同时我们还会做高性能数据采集,并行采集所有服务数据。

  七.DTS设计

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

  在整个集群中,除了基本的运维管理,还需要有数据传输服务,DTS就是主要来解决类似数据迁移的场景,它的设计有以下几个要点:

  首先是一个分布式架构,不能有单点;在做云之间的数据迁移时,中间跨互联网的带宽可能不太大,所以我们将窄宽带下的传输效率优化得比原生还要好;支持全量+增量的传输方式;支持GTIB和并行回放;在输出端支持Kafka中间件消息队列,可以对接下游的大数据平台;兼容主流的云厂商产品,阿里云、微软云和原生MySQL。

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

  上图是DTS架构的设计图,分为两层。Manager是通过leader+follower的方式去做高可用,如果leader挂了的话,备节点会重新选主,并将数据源数据保存到KV存储里,它们之间通过SLA来通讯。Agent既可以作为数据的提取端,也可以作为数据的回放端,通过提取端从MySQL的binlog当中提取日志信息,然后传递给回放端,回放端并行回放日志。manager负责整个集群的任务调度,并把任务分配给agent,这样的话一个集群可以管理多套数据库服务。

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

  上图是我们DTS的界面设计。

  八.未来规划

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

  关于我们整个产品的未来规划,我们有以下几个思路。

  第一, 因为现在很多企业都在使用开源数据库,所以我们会考虑将能够解决比较多场景的开源数据库也在平台上统一管理起来,例如Redis、ES、PG等等。

  第二, 容器化现在很火热,我们也在思考如何把容器化和产品结合起来,这样在数据库版本迁移的时候,不需要每次都做内部兼容。

  第三, 虽然大家对云的概念接受度已经很高了,但是企业,尤其是大型企业并不会把所有数据上云,通常都会是私有云+公有云的混合云模式。我们在思考如何在私有云环境下管理供应商的所有数据库服务。

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

  以上是我们系列产品的展示,DMP主要来解决运维管理,RDS解决数据库服务,Shard解决水平的分库分表,Guard解决高可用,Proxy解决读写分离,DTS解决数据同步数据迁移。

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

  另外,我们还做了一个开源的中间件,和我们的Shard内核一样,但云树Shard主要解决例如管理高可用、配置管理等等功能,而这个中间件可以在企业内部解决Shard的某一个场景。另外,这个中间件与MyCat完全兼容,但解决了MyCat缺少维护、存在的bug等等一些问题。

0
相关文章