打开思路，数据库的全场景高可用性架构长什么样？数据库智能管家的创新与探索

本文讲了打开思路，数据库的全场景高可用性架构长什么样？数据库智能管家的创新与探索。

数据库是企业核心业务运行的重要组成部分，数据是企业的生命线，如果数据库出现宕机、数据丢失或不可用等问题，将会对企业的生产、营销和决策产生难以预估的影响，因此，一套高可用的数据库架构对于企业来说至关重要，可以最大化保证业务稳定性和数据可靠性。

架构概述

数据库的架构就好比房屋建造结构，如果一个房子只有一扇门和一片玻璃窗，那么一旦遭到攻击或破坏，整个房子就处于危险状态。同样，一个没有高可用架构的应用程序，在面临硬件设备故障、网络瘫痪、自然灾害以及人为错误等问题时，也很容易受到威胁。高可用架构就像房屋加固结构和消防系统，在故障发生时实现快速恢复，最大化降低损失。

但是，我国业内尚未给出一套完整的全场景高可用性架构解决方案。该架构基于跨可用区部署、异地备份保障，搭配数据库代理和弹性CPU能力，结合配套生态工具共同打造，可有效提高系统稳定性和可用性、减少业务停机时间和数据丢失率、提高故障诊断和恢复效率、提升数据处理能力和响应速度等，全方位全流程保障业务稳定运行。

全场景高可用性架构可为用户的实际业务带来诸多帮助，主要包括以下方面：

1. 提升稳定性：云数据库MySQL全场景高可用性架构的可扩展性强，在突发流量场景和热点场景下优势更为明显，通过新增实例或数据库代理节点，均衡各个实例之间的负载，实现系统的快速扩容；支持CPU自动弹性扩缩容，保障业务平稳运行的同时轻松应对流量高峰；在跨可用区部署架构中，就近访问能力也可帮助用户降低网络延时，助力前端业务丝滑体验；

2. 保障可用性：云数据库MySQL全组件实现跨可用区/跨地域部署，降低单点故障风险，即某个可用区或某个实例出现故障，可自动切换到其他可用区上的备用节点，整个系统仍可以保持稳定运行；其次，通过将数据库部署在多地数据中心，可以实现跨区域容灾，从而降低故障发生的概率。此外，通过备份、数据同步（三节点支持强同步）等机制，可以减少业务停机时间和数据丢失率，提高了业务的容灾性和数据可靠性、完整性；

3.提高数据处理能力和响应速度：通过数据库代理将负载分布到多个数据库节点上，从而提高数据处理能力和响应速度。同时，可自动将流量切换到正常运行的节点上，避免了数据库节点故障导致的数据访问异常；

4.提高故障诊断和恢复效率：通过数据库智能管家DBbrain 7*24h监控，帮助DBA快速定位问题解决问题；同时，备份、数据同步等机制也有助于故障恢复和数据恢复，缩短故障修复时间；

综上所述，

配置细节

在新版控制台界面上，云数据库MySQL从可用性、性能、安全三个方面出发，提供给用户数据库功能配置详情。用户可根据业务情况，选择可用性级别，参考对应配置。此处，我们选择全场景高可用性架构配置，用户可参考各配置项状态栏查看当前实例是否已具备该能力。

2.1 高可用架构部署

全场景高可用性架构部署包含跨可用区主实例、异地跨可用区灾备实例以及跨地域备份组成。跨可用区部署是指将数据库系统分布在多个可用区中，以提高系统的可用性和容错性。简单来说，就是将数据库备份到不同的可用区，从而保证在某个可用区发生故障时，其他可用区中的数据库可以继续服务。

跨可用区部署的优点在于提高了数据库系统的可用性和容错性，从而降低了系统的单点故障风险。另外，它还能降低访问延迟，提高了用户请求响应速度，从而保证业务更加稳定和可靠。

全场景高可用性架构建议用户选择三节点进行配置，三节点采用一主两备架构，支持强同步复制方式，能为用户提供金融级的可靠性和高可用性。以图1为例，全场景高可用性架构支持业务的跨可用区部署，具体方案如下：

1. 主实例部署在广州三区，主要负责读写操作，提供主要的服务访问入口；

2. 备节点分别部署在广州三区和广州六区，从主实例处同步数据，并实现数据备份和灾备故障转移；

3. 备份中心可以同时部署在广州三区和北京地域中，以保证数据的安全可靠性；

4. 灾备实例部署在上海地域，灾备主实例和灾备备节点分别部署在上海八区和上海五区，负责备份主实例的数据，并在灾难恢复期间提供主要数据处理和服务能力，从而保证数据库的高可用性和稳定性；

5. 数据库的跨可用区部署可以通过数据库代理将请求转发到不同的数据库实例，并保证请求可靠到达和响应，从而提高系统的响应速度和可用性。同时，可在多个可用区内设置只读实例，实现读写分离，降低主实例读负载压力；

如果广州三区的主实例不幸宕机，全场景高可用性架构可提供三重保障机制，确保业务在主实例宕机后的快速恢复和无缝切换，减少由此带来的损失，方案如下：

1. 备节点接管：当主实例宕机后，备节点可以在数秒内自动接管为主实例，成为新的主节点，并提供读写服务。此时，业务可以无需任何手动干预，无缝切换到新的主节点上继续提供服务；

2. 灾备节点接管：如果备节点也无法正常提供服务，灾备节点被快速拉起接管为主节点，以保证业务的无缝切换和高可用性；

3. 备份中心及时恢复数据：此外，备份中心也会及时备份主实例的数据，并在主实例不可恢复的情况下，恢复数据到可用实例上，以保证业务的完整性和稳定性；

2.2 数据库代理（proxy）

数据库代理是介于数据库应用程序和数据库服务器之间的中间层，主要是用于处理数据库请求和响应等工作。云数据库MySQL提供的数据库代理具体支持以下能力：

1. 读写分离

数据库代理相当于是个中转站，可以将所有请求按权重分发给数据库的主从节点、只读实例，以此实现读写分离，从而降低主库负载，提高整个系统的性能和可用性，尤其适用于请求量高、连接数多的业务。同时，proxy支持开启事物拆分能力，可将一个事物内的读和写分发到不同实例上去执行，以此降低主实例负载。同时，数据库代理采用集群架构部署，多节点可保证故障平滑转移。

2. 独立访问

云数据库MySQL提供的数据库代理服务可独立于主实例访问，即数据库代理拥有独立的访问地址，最大程度降低网络安全风险和维护成本。更高级的，用户可根据业务的需要通过不同的代理节点进行负载分配，给到不同业务相应的代理地址即可。

3. 跨可用部署+就近访问

基于云数据库MySQL跨可用区部署特性，proxy也支持跨可用区挂载，就近的客户端流量自动路由到相应的代理节点上（即就近访问功能），以提高访问效率和降低延迟。

在默认权重配置下，全场景高可用性架构会自动选择最短访问路径。

以图3为例，当客户端从北京七区发送读写访问请求时，系统会优先将读写请求送往北京七区的数据库代理节点，北京七区的数据库代理节点会进行读写分离操作，将读请求优先送往同可用区的只读实例，将写请求送往主实例。

4. 防闪断能力

在数据库运维中，会根据业务的需要经常对实例进行调整，例如配置变更、计划内HA切换、计划内重启等，此类操作往往会中断会话，导致连接闪断、新建连接失败等问题。proxy提供的防闪断能力就是用来解决此类场景下可能出现的连接问题。当proxy感知到计划内的有损行为时，就会与切换前的主节点断开连接，将客户端到proxy上的连接恢复至切换后主节点的连接上，通过 session track 能力将会话相关的系统变量、用户变量、字符集编码信息转移至新的后端连接上，实现对应用程序端无损切换。

经过测试，在主备切换、内核小版本升级、调整实例规格的场景下，云数据库MySQL可保持100%的连接保活率。

2.3 CPU弹性扩容

CPU弹性扩容是云数据库MySQL最新推出的能力项，指的是基于云环境通过动态分配CPU资源，可实现CPU资源的手动/自动调整和弹性扩展，主打一个快速响应和变更。当数据库访问量增加或CPU资源占用率上升时，可以自动添加更多的CPU资源，并在高峰期结束后自动缩减。这种弹性扩容的方式，能够使用户根据业务的需求和业务量动态地配置数据库的CPU资源，从而确保更好的数据库性能、可用性和稳定性，提高平台的弹性和可靠性。

使用CPU弹性扩容的好处主要体现在：

1. 弹性控制成本：CPU弹性扩容可以保证在高峰期为用户提供更加稳定的服务，避免由于CPU资源瓶颈造成的性能下降和不可用性问题，同时在业务需求下降时又可以自动缩减资源，减少浪费和费用；

2. 提高灵活性：弹性扩容可以根据业务需求和用户量自动调整CPU资源，大大提高平台的灵活性和可扩展性。使用弹性扩容功能的数据库系统，在弹性调整过程中能够更好地适应不断变化的业务需求和用户数量，从而可以快速扩展或缩小规模；

3. 提高性能和可用性：弹性扩容功能可以根据实时的CPU使用情况，动态地调整CPU资源的分配，以加快数据库的响应速度和提高数据库的可用性，从而更好地满足业务需求；

2.4 配套生态工具

1. DBbrain智能管家，7*24h全方位监测，第一时间发现问题定位问题

云数据库MySQL全面接入DBbrain，可实现数据库性能监控、安全检测和优化诊断，通过智能分析和建议，协助用户快速解决数据库性能和安全问题，提升数据库效率和用户体验。具体地，DBbrain可提供KILL会话功能、SQL限流能力、热点更新保护能力，并且可开启自治服务，无需人工干预；在诊断分析能力上，DBbrain可提供慢SQL分析、空间分析、SQL优化、审计日志分析等能力，7*24h全方位诊断优化。

2. 混沌演练平台，全真模拟真实业务场景，提前预知应用情况

演练平台可以帮助用户模拟各种突发事件和异常场景，提高系统的容错能力和可靠性。搭建好真实的数据库架构后，平台会对业务进行全方位的压力测试，对传统的异常场景进行模拟并进行自动化部署管理，从而能够更好地发现和诊断系统中的潜在问题，以提升业务的质量和可靠性。

就近访问能力

性能测试

为了更好的向读者展现全场景高可用性架构的性能情况，在测试环境保持一致的条件下，我们做了三组对比测试：

3.1 测试环境

地域：北京 - 北京六区、北京七区；

客户端规格：CVM，4C16G；

客户端操作系统：TencentOS Server 3.2；

测试实例规格：主实例通用型4C16G，只读实例4C16G，数据库代理1.3.5 2核4000MB；

测试实例版本：MySQL 8.0；

测试工具：SysBench 1.0.20；

测试数据量：10 tables 100t；

3.2 测试详情

三组对比测试主要用于比较同可用区部署和跨可用区部署之间的性能差异，以及数据库代理提供的就近访问功能的性能情况。

第一组：同可用区部署

部署搭配为：CVM(七区)+主实例(七区)+数据库代理(七区)+只读实例(七区)

第二组：跨可用区部署

部署搭配为：CVM(六区)+主实例(七区)+数据库代理(七区)+只读实例(七区)

第三组：跨可用区部署就近访问

部署搭配为：CVM(六区)+主实例(七区)+数据库代理(六区、七区)+只读实例(六区、七区)

3.3 测试结果

由于全场景高可用架构中的就近访问能力最突出的性能表现就是降低跨可用区访问的响应时间（Response Time，RT），我们重点关注时延的测试结果。测试结果如下图所示，可以看出：就近访问能力使得跨可用区部署也能有更低的网络延迟，在低并发下效果更加显著，就近访问的响应时长最佳可达到跨可用区访问响应时长的17%。

近些年，传统的数据库运维方式已经越来越难于满足业务方对数据库的稳定性、可用性、灵活性的要求。随着数据库规模急速扩大，各种NewSQL系统上线使用，运维逐渐跟不上业务发展，各种矛盾暴露的更加明显。在业务的驱动下，美团点评DBA团队经历了从“人肉”运维到工具化、产品化、自助化、自动化的转型之旅，也开始了智能运维在数据库领域的思考和实践。

本文将介绍美团点评整个数据库平台的演进历史，以及我们当前的情况和面临的一些挑战，最后分享一下我们从自动化到智能化运维过渡时，所进行的思考、探索与实践。

数据库平台的演变

我们数据库平台的演进大概经历了五个大的阶段：

第一个是脚本化阶段，这个阶段，我们人少，集群少，服务流量也比较小，脚本化的模式足以支撑整个服务。

第二个是工具化阶段，我们把一些脚本包装成工具，围绕CMDB管理资产和服务，并完善了监控系统。这时，我们的工具箱也逐渐丰富起来，包括DDL变更工具、SQL Review工具、慢查询采集分析工具和备份闪回工具等等。

第三个是产品化阶段，工具化阶段可能还是单个的工具，但是在完成一些复杂操作时，就需要把这些工具组装起来形成一个产品。当然，并不是说这个产品一定要做成Web系统的形式，而是工具组装起来形成一套流程之后，就可以保证所有DBA的操作行为，对流程的理解以及对线上的影响都是一致的。我们会在易用性和安全性层面不断进行打磨。而工具产品化的主要受益者是DBA，其定位是提升运维服务的效率，减少事故的发生，并方便进行快速统一的迭代。

第四个是打造私有云平台阶段，随着美团点评业务的高速发展，仅靠十几、二十个DBA越来越难以满足业务发展的需要。所以我们就把某些日常操作开放授权，让开发人员自助去做，将DBA从繁琐的操作中解放出来。当时整个平台每天执行300多次改表操作；自助查询超过1万次；自助申请账号、授权并调整监控；自助定义敏感数据并授权给业务方管理员自助审批和管理；自定义业务的高峰和低峰时间段等等；自助下载、查询日志等等。

第五个是自动化阶段，对这个阶段的理解，其实是“仁者见仁，智者见智”。大多数人理解的自动化，只是通过Web平台来执行某些操作，但我们认为这只是半自动化，所谓的自动化应该是完全不需要人参与。目前，我们很多操作都还处于半自动化阶段，下一个阶段我们需要从半自动过渡到全自动。以MySQL系统为例，从运维角度看包括主从的高可用、服务过载的自我保护、容量自动诊断与评估以及集群的自动扩缩容等等。

现状和面临的挑战

下图是我们平台的现状，以关系数据库RDS平台为例，其中集成了很多管理的功能，例如主从的高可用、MGW的管理、DNS的变更、备份系统、升级流程、流量分配和切换系统、账号管理、数据归档、服务与资产的流转系统等等。

而且我们按照逻辑对平台设计进行了划分，例如以用户维度划分的RDS自助平台，DBA管理平台和测试环境管理平台；以功能维度划分的运维、运营和监控；以存储类型为维度划分的关系型数据库MySQL、分布式KV缓存、分布式KV存储，以及正在建设中的NewSQL数据库平台等等。未来，我们希望打造成“MySQL+NoSQL+NewSQL，存储+缓存的一站式服务平台”。

挑战一：RootCause定位难

即便我们打造了一个很强大的平台，但还是发现有很多问题难以搞定。第一个就是故障定位，如果是简单的故障，我们有类似天网、雷达这样的系统去发现和定位。但是如果故障发生在数据库内部，那就需要专业的数据库知识，去定位和查明到底是什么原因导致了故障。

通常来讲，故障的轨迹是一个链，但也可能是一个“多米诺骨牌”的连环。可能因为一些原因导致SQL执行变慢，引起连接数的增长，进而导致业务超时，而业务超时又会引发业务不断重试，结果会产生更多的问题。当我们收到一个报警时，可能已经过了30秒甚至更长时间，DBA再去查看时，已经错过了最佳的事故处理时机。所以，我们要在故障发生之后，制定一些应对策略，例如快速切换主库、自动屏蔽下线问题从库等等。除此之外，还有一个比较难的问题，就是如何避免相似的故障再次出现。

挑战二：人力和发展困境

第二个挑战是人力和发展的困境，当服务流量成倍增长时，其成本并不是以相同的速度对应增长的。当业务逻辑越来越复杂时，每增加一块钱的营收，其后面对应的数据库QPS可能是2倍甚至5倍，业务逻辑越复杂，服务支撑的难度越大。另外，传统的关系型数据库在容量、延时、响应时间以及数据量等方面很容易达到瓶颈，这就需要我们不断拆分集群，同时开发诉求也多种多样，当我们尝试使用平台化的思想去解决问题时，还要充分思考如何满足研发人员多样化的需求。

人力困境这一问题，从DBA的角度来说，时间被严重的碎片化，自身的成长就会遇到瓶颈，比如经常会做一些枯燥的重复操作；另外，业务咨询量暴增，尽管我们已经在尝试平台化的方法，但是还是跟不上业务发展的速度。还有一个就是专业的DBA越来越匮乏，越来越贵，关键是根本招聘不到人手。

在这种背景下，我们必须去思考：如何突破困局？如何朝着智能化转型？传统运维苦在哪里？智能化运维又能解决哪些问题？

首先从故障产生的原因来说，传统运维是故障触发，而智能运维是隐患驱动。换句话来说，智能运维不用报警，通过看报表就能知道可能要出事了，能够把故障消灭在“萌芽”阶段；第二，传统运维是被动接受，而智能运维是主动出击。但主动出击不一定是通过DBA去做，可能是系统或者机器人操作；第三，传统运维是由DBA发起和解决的，而智能运维是系统发起、RD自助；第四，传统运维属于“人肉救火”，而智能运维属于“智能决策执行”；最后一点，传统运维需要DBA亲临事故现场，而智能运维DBA只需要“隐身幕后”。

从自动化到智能化

那么，如何从半自动化过渡到自动化，进而发展到智能化运维呢？在这个过程中，我们会面临哪些痛点呢?

我们的目标是为整个公司的业务系统提供高效、稳定、快速的存储服务，这也是DBA存在的价值。业务并不关心后面是MySQL还是NoSQL，只关心数据是否没丢，服务是否可用，出了问题之后多长时间能够恢复等等。所以我们尽可能做到把这些东西对开发人员透明化，提供稳定高效快速的服务。而站在公司的角度，就是在有限的资源下，提升效率，降低成本，尽可能长远地解决问题。

上图是传统运维和智能运维的特点分析，左边属于传统运维，右边属于智能运维。传统运维在采集这一块做的不够，所以它没有太多的数据可供参考，其分析和预警能力是比较弱的。而智能运维刚好是反过来，重采集，很多功夫都在平时做了，包括分析、预警和执行，智能分析并推送关键报表。

而我们的目标，是让智能运维中的“报警+分析+执行”的比重占据的越来越少。

决策执行如何去做呢？我们都知道，预警重要但不紧急，但报警是紧急且重要的，如果你不能够及时去处理的话，事态可能会扩大，甚至会给公司带来直接的经济损失。

预警通常代表我们已经定位了一个问题，它的决策思路是非常清晰的，可以使用基于规则或AI的方式去解决，相对难度更小一些。而报警依赖于现场的链路分析，变量多、路径长，所以决策难，间接导致任何决策的风险可能都变大。所以说我们的策略就是全面的采集数据，然后增多预警，率先实现预警发现和处理的智能化。就像我们既有步枪，也有手枪和刺刀，能远距离解决敌人的，就尽量不要短兵相接、肉搏上阵。

数据采集，从数据库角度来说，我们产生的数据分成四块，Global Status、Variable，Processlist、InnoDB Status，Slow、Error、General Log和Binlog；从应用侧来说，包含端到端成功率、响应时间95线、99线、错误日志和吞吐量；从系统层面，支持秒级采样、操作系统各项指标；从变更侧来看，包含集群拓扑调整、在线DDL、DML变更、DB平台操作日志和应用端发布记录等等。

数据分析，首先是围绕集群分析，接着是实例、库，最后是表，其中每个对象都可以在多项指标上同比和环比，具体对比项可参考上图。

通过上面的步骤，我们基本可以获得数据库的画像，并且帮助我们从整体上做资源规划和服务治理。例如，有些集群实例数特别多且有继续增加的趋势，那么服务器需要scale up；读增加迅猛，读写比变大，那么应考虑存储KV化；利用率和分布情况会影响到服务器采购和预算制定；哪几类报警最多，就专项治理，各个击破。

从局部来说，我们根据分析到的一些数据，可以做一个集群的健康体检，例如数据库的某些指标是否超标、如何做调整等等。

数据库预警，通过分析去发现隐患，把报警转化为预警。上图是我们实际情况下的报警统计分析结果，其中主从延迟占比最大。假设load.1minPerCPU比较高，我们怎么去解决？那么，可能需要采购CPU单核性能更高的机器，而不是采用更多的核心。再比如说磁盘空间，当我们发现3T的磁盘空间普遍不够时，我们下次可以采购6T或更大空间的磁盘。

针对空间预警问题，什么时候需要拆分集群？MySQL数据库里，拆分或迁移数据库，花费的时间可能会很久。所以需要评估当前集群，按目前的增长速度还能支撑多长时间，进而反推何时要开始拆分、扩容等操作。

针对慢查询的预警问题，我们会统计红黑榜，上图是统计数据，也有利用率和出轨率的数据。假设这是一个金融事业群的数据库，假设有业务需要访问且是直连，那么这时就会产生几个问题：第一个，有没有数据所有者的授权；第二个，如果不通过服务化方式或者接口，发生故障时，它可能会导致整个金融的数据库挂，如何进行降级？所以，我们会去统计出轨率跟慢查询，如果某数据库正被以一种非法的方式访问，那么我们就会扫描出来，再去进行服务治理。

从运维的层面来说，我们做了故障快速转移，包括自动生成配置文件，自动判断是否启用监控，切换后自动重写配置，以及从库可自动恢复上线等等。

报警自动处理，目前来说大部分的处理工作还是基于规则，在大背景下拟定规则，触发之后，按照满足的前提条件触发动作，随着库的规则定义的逐渐完善和丰富，可以逐步解决很多简单的问题，这部分就不再需要人的参与。

展望

未来我们还会做一个故障诊断平台，类似于“扁鹊”，实现日志的采集、入库和分析，同时提供接口，供全链路的故障定位和分析、服务化治理。

展望智能运维，应该是在自动化和智能化上交叠演进，在ABC（AI、Big Data、Cloud Computing）三个方向上深入融合。在数据库领域，NoSQL和SQL界限正变得模糊，软硬结合、存储计算分离架构也被越来越多的应用，智能运维正当其时，我们也面临更多新的挑战。我们的目标是，希望通过DB平台的不断建设加固，平台能自己发现问题，自动定位问题，并智能的解决问题。

上文就是小编为大家整理的打开思路，数据库的全场景高可用性架构长什么样？数据库智能管家的创新与探索。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。