MySQL海量运维管理如何保障京东大促？

　　本文转载自dbaplus社群
　　本文根据高新刚老师在〖2020 Gdevops全球敏捷运维峰会〗现场演讲内容整理而成。
　　（点击文末＂阅读原文＂可获取完整PPT）
　　讲师介绍
　　高新刚，京东数科数据库团队负责人，负责京东数科数据库平台的管理维护工作，带领团队平稳护航多次6·18、11·11的大促活动；对数据库多业务场景架构设计，高并发解决方案，数据生态管控有着丰富的实践经验；对数据库库中间件、分布式事务数据库和自动化智能化运维平台设计开发有着深入的实践和探索；长期专注于数据库产品化输出和国产数据库的探索研究。
　　当我们遇到海量这个词的时候，大家第一时间会想到和数据库相关的哪些内容？比如海量的数据量、大规模的数据库的节点数、高并发的业务访问。海量的数据带来的是存储和弹性扩展的问题，大规模的数据库节点给我们带来的是批量运维的困扰，高并发访问带来的是性能的问题。
　　所以我认为，解决大部分的海量数据的问题，一般有三种通用的方法：
　　第一、我们要有一个数据的全生命周期的管理体系，从数据库的写入到数据库的存储，到TP的查询，AP的查询，到后面的一些冷热数据分离和大数据实时或异步抽取，我们要有一系列的管控工具帮助我们实现高效的解决方案；
　　第二、我们要有一个非常稳定、平稳高效的架构体系，也就是说不管你怎么去做弹性的缩扩容，不管你怎么去做数据的搬迁，也都是在这一个相对固定的TP和AP的架构框架下面去运行；
　　第三、我们还需要有一个自动化运维的管控平台，如果你有一个非常完善的数据库生态管控的平台体系，那么你就能够很轻松地去驾驭这种海量的数据库运维工作。
　　所以说今天我的议题也是从里面找了几个点，来给大家分享。通过海量运维的概述，给大家介绍一下我们是怎么去做数据生态管控的，以及我们一些数据库管控组件的功能介绍。其次想给大家介绍一下在面临大规模的数据库节点运维的时候，我们如何去搭建高可用的容灾体系，或者说如何去做高可用解决方案的选型。接下来会通过介绍资源的管理和告警信息的管理，告诉大家我们的一些自动化运维的思想是什么。最后就是我们会把海量运维的管理思想在大促备战中进行应用和实践。
　　一、海量运维概述
　　首先整体来说这是我们公司的一个数据库运维拓扑图，中间是整个数据库集群，不管是单库还是水平拆分的，应用都是通过智能DNS或者vip访问数据库的，如果是单库就直接连到主从架构，如果是水平拆分就是通过Sharding-Sphere或者CDS数据库中间件产品访问后面的数据节点。
　　在这里我们可以在中间件这层实现数据加密和脱敏的数据管控目标。如果你要是单库的话，我们这个数据加密和脱敏是放在应用的代码里面，如果你要是用水平拆分的话，分布式中间件天然就支持加密脱敏的方法。
　　接下来数据写入到数据库之后，左右两侧其实就是数据的一些流转功能。DBRep和DTS主要指的是实现数据流转到AP的查询平台，流转到一些运营后台的其他业务逻辑的查询数据库里面去。左边Archiver是数据归档平台，实现数据冷热分离。还有PillBOX是备份管控的平台，可以把数据库的备份按照一定的规则策略传入到Hadoop，再传到磁带库里，这样整体来说数据库备份的整个生命周期可以得到很好的管控。从online环境传输到nearline环境，最后进入到offline的磁带库中，再结合备份保留策略以及逆向的恢复功能，备份平台可以覆盖数据库备份恢复的所有需求功能。
　　下面就是DBA运维的一些管控。DBCM就是一个建模平台，所有数据库的建库建表逻辑要通过这个平台来创建，如果不通过这个平台，大家可以想到，在这种大数据后期的一些建设中，你就会发现你的数据的质量会有很严重的问题，不管是元数据还是业务数据都或多或少出现数据质量问题，所以说通过建模平台我们做到了从建模源头开始规范和引导研发的业务模型设计。
　　其次是查询平台，研发在做开发的时候，包括业务运营人员需要对数据库进行一些数据查询、获取，查询平台里面会包含一些加密、脱敏、查询记录条数和导出的一些管控限制的功能，通过这种方式我们能够很好的做到企业级安全合规的管控和限制。
　　CleverDB是性能管控平台，我们可以给研发DBA还有一些其他想关注数据库的人员一个非常友好的可视化平台，对于研发用户来说数据库就是一个黑盒产品，通过这种可视化的管理，可以讲一些专业化的性能指标转换为数字化，以可视化的解决展示给我们的需求方，这样可以驱动他们自主管理各自业务数据库。在大规模运维体系中，研发自驱管理数据库和数据库自助化服务逐渐成为新生的运维力量。
　　OnLine平台是一个流程管控平台，不管做变更也好，做大规模的架构调整也好，都需要一个企业级的合规流程才能完成这个动作。最后就是自动化运维平台，我们在管理上万台服务器的时候，就是通过这些平台工具提升运维效率的，总之拥有一个完整的数据库生态的工具平台，然后基于这个平台逐渐实现自动化、流程化、智能化，是驾驭海量运维场景必经之路。
　　二、海量运维的高可用体系
　　其次我想说的是通过高可用体系的介绍，让大家去了解如何在这种海量的节点运维过程中，如何做这种容灾体系的建设或者去做选型这块的逻辑。
　　1、优质的容灾服务质量
　　提供优质的容灾服务质量，RTO<10s。它主要的逻辑流程通过秒级监控可以快速感知故障，然后通过的哨兵探测逻辑，可以验证监控结果的准确性，第三步调用核心切换模块，进行切换环境检查、数据一致性校验、主从切换、vip映射关系变更、元数据信息变更、切换消息通知等。最终实现容灾管控自动化，实现故障自愈。
　　2、良好的兼容性和适配性
　　第二点我们要考虑到容灾体系的兼容性和适配性，因为在一个企业里面其实你的数据库的架构并不完全标准的一模一样。比如说业务会分等级，分等级之后主库从库的数量会随着业务等级的不一样会有一些变化，还有有些业务会做跨机房的容灾，还会做多活、多中心的架构。所以高可用容灾体系要具备良好的兼容性和适配性，比如要兼容不同的架构，不同的版本，不同接入方式和不同的资源环境。
　　3、可靠的切换决策模型
　　当故障发生时，切换之前的故障探测、故障场景的分析以及切换决策的逻辑，这些方面要远远比切换本身重要。所以这个模型能帮助我们辨识极端场景，避免错误切换或者脑裂问题。举个例子，比如有一个人突然间身体发生了状况，首先最重要的是要及时发现他有问题，第二及时送到医院，接下来医生要及时判别他到底是什么样的问题，最后才能做紧急的治疗和抢救措施。所以说这个决策模型其实做的就是发现和诊断的过程。
　　4、服务自身的可用性保障
　　第四点就是服务自身的可用性保障。也就是说如果真的出现机房级别的宕机时，其实高可用服务也是挂了的，你如何能够在另外一个机房把你的高可用服务拉起来，然后在高可用服务启动之后才能去做机房级的容灾，所以这种能力也是需要大家再去考虑的一个点。
　　5、平台自动化的管控
　　第五点就是平台自动化的管控。通过配置的统一管理，包括切换进度、历史查询的这些功能，可以帮助我们在大规模数据库运维背景下去提高我们容灾的效率，同时丰富的API接口和可视化信息，能够提供一些非常良好的兼容性和适配性。
　　6、丰富的容灾类型
　　最后就是丰富的容灾类型。我们一般情况下都会做主库容灾，像MHA是一个主库容灾的能力，其实它不能提供从库的容灾。然后在容灾类型上面，也要考虑手动切换、自动切换，因为我们会做一些切换演练，比如我们做大促准备的时候经常做一些切换演练，主从切换、主备切换、跨机房的批量切换，这种能力都是需要在高可用体系里面去体现出来的。
　　三、海量资源管理
　　资源管理其实就是以前我们在规模非常小的时候用Excel管理数据库资源，但是现在公司的规模越来越大，数据库的节点数越来越多，自动化平台建立起来之后我们会发现有很多维度的元数据需要我们做管控。
　　1、资源自动上报
　　首先资源节点自动上报，例如公司采购了一百台机器，这些机器怎么录入到这个系统里面？我们是通过给每台机器装一个agent端，它会自动上报它的IP，还有这些机器所在的网段、机房、机柜等信息是通过跟IT运维系统去进行对接，通过他们提供的API接口把这些信息抓过来，这样你的信息才能健全。
　　2、服务器使用状态的管理
　　第二点就是服务器使用状态的管理，比如这个服务器到底有什么样的业务在使用，有没有报错，有没有报修，它的维修进度是什么，这些都需要在我们的系统里记录。
　　我们在以前就出现过类似的问题，比如说我们要给这台机器去做维修了，因为一些元数据的不准确，可能那台服务器上还有一些其他业务运行，导致那个业务就因为关机而中断了服务，所以元数据的准确性也非常重要。
　　3、数据库与业务研发匹配
　　第三，数据库跟业务这种两个视角的同步和串联的问题。也就是说我的数据库只记录了它是什么样的架构，它跟业务的对应关系没有建立起来，是两个业务的数据库，这个数据库又被哪些业务所访问，包括这些业务是哪些研发负责人去负责的，我们需要把这些相关的信息串联起来，最后形成一个血缘关系，或者知识拓扑图，让大家能够很清晰地了解到我们的元数据的信息是什么样的。
　　4、元数据变更管理
　　第四，元数据的变更，比如你做了主从的切换，服务器的维修，包括一些服务器的名字的变更，所有这样的事情。以及比如说研发负责人、公司组织架构调整、部门信息的调整，对应到数据库的管控里面，元数据都会涉及到一系列的变更。
　　5、资产管理
　　第五就是资产的管理。作为DBA要能够给到各个业务部门提供数据库服务器使用情况，能够告诉业务部门负责人，这个季度或者这半年服务器资产使用的情况，这种所谓的报表或者视图的信息，也是需要提供的。
　　6、API服务
　　最后就是API服务，因为作为一个数据库来说，它只是在IT系统里面其中一个平台，所以它要跟其他的平台去进行信息的交互，通过信息的交互，才能够把所有运维体系的数据串联起来。
　　四、海量告警管理
　　告警管理也是运维体系中非常关键的管理维度，在我们机器非常多的情况下，每天会收到很多告警。许多人私底下聊天的时候经常表达今天收到好几千条告警，以此来证明他们公司数据库规模有多庞大。其实我觉得这是不对的，应该告诉大家，我们数据库规模非常大，但是我们每天只收几十条告警。以此来证明我们有非常强大的运维管控能力。
　　怎么做到的？其实就是通过告警的管理，通过一系列的方法去实现告警数量的降低，有效告警能够很直接，很清晰的暴露出来，而不会被海量的告警信息所淹没。
　　1、触发告警
　　我们现在很多公司的监控告警体系都停留在第一阶段，就是我们制定各种指标的告警基线，设置告警级别，通过这种方式去给相关的业务负责人，相关的运维人员发告警短信。在这种情况下其实是没有任何过滤信息的，只要你触发了这个基线，你就会收到告警信息。
　　实际情况是什么样的？给大家举个例子，主从延时这件事，当你做一个大事务的时候，重复延时可能是相当长的时间，有可能是半小时或者一个小时，半个小时之内可能每隔两三分钟就收一条告警，其实对于运维人员来说，他是不在意的，他知道这是一个大事务，他知道这个事务要继续做下去，所以就会有第二个方法，就是汇总分析。
　　2、汇总分析
　　汇总分析是什么？其实说白了就是一个告警的收敛，我们会把一些连续重复的告警进行一个收敛，然后减少接收人员接收到的告警条数。
　　再一个就是单因多果的分析，比如说这台机器宕机了，你会收到一条宕机的告警，同时你会收到一堆其他的告警，比如连接数访问异常，还有主从中断，你会收到一堆这样的告警，其实最有用的一条告警就是机器宕机。
　　所以我们要通过单因多果的关联分析，最终找到根因点是什么，这也是一个我们在运维里面根因分析的一种方法，通过这个模型我们可以去把最根本的原因找出来，然后发给相关的运维人员，避免有用的信息被海量的告警信息所淹没这种情况。
　　3、以点推面
　　第三个就是以点推面，这里有两个场景：一个就是场景就像我刚才说的在主库执行一个大事务，我肯定能够预判到在之后的未来的半个小时之内，所有的从库都会有延时，这个时候运维人员可以干预一下告警决策，告诉他半个小时之内这些从库可以不发延时告警。
　　再一个比如我们在大促之前会做切换容灾演练，主从切换的时候势必也会发一些告警，这些告警一般都是在夜里做容灾切换演练的，所以如果这个时候去发告警，会影响好多人的休息，比如相关、不相关的业务人员，他都会收到机器切换的告警。所以在计划内的一些切换的时候，其实我们也是可以预判到的，然后提前将这些告警信息进行一个参数的调整，去避免这样的事情。
　　4、调节基线
　　再一个就是基线的调整。比如像大促的时候，双十一、双十二的时候，高峰之前的时候，我们能预判到整个告警基线，或者告警参数需要进行一个很大的调整。比如说并发数，比如说事务的超时时间，我们可能都要做一个调整，来满足大促峰值的冲击压力，不至于大促来临那一刻，你的手机都有可能接收过多的短信。
　　5、精确告警
　　经过一系列的调整和模型的建设，最后达到的效果就是减少无用的告警，减少运维人员和研发人员的感官的疲劳，同时他也能够减少告警短信的成本。
　　五、大促备战分享
　　然后给大家分享一下我们大促的整个过程，其实这个过程就分为三个部分：
　　首先是备战部分，备战之前基本上是提前一个月到一个半月的时候开始准备，接下来主要介绍一下在面对多大规模的服务器的时候，我们不可能把所有的数据库节点都one by one管理起来，那我们如何去做运维呢？
　　第一条，要给研发赋能，使相应的业务研发人员具备管理自己数据库的能力。你可以给他一个引导或者给他一个类似数据库巡检报告这样的东西，让他意识到他自己的数据库有哪些问题。让他先优化一轮，减少对所有数据库运维的压力；
　　第二就是要抓核心链路的数据库，比如说像京东，在双十一或者双十二的时候，核心链路是在支付、白条、运费险，在这些业务上面我们就需要DBA的直接的关注，要抓它的核心链路；
　　第三，作为DBA要时刻看一下运维管控的系统是否正常的运行，比如监控告警体系、容灾体系、备份恢复的能力、流程变更。保障基础服务稳定运行，做好监控的监控和服务的服务是非常重要的；
　　第四，应急预案。
　　在这些点上如果作为DBA能够很好的管控的话，其实整个大促的过程应该还是相对比较轻松的。
　　下图就是大促过程中比较核心要去关注的几个点，如果你要去支持一个数据库的大促运维，或者说去做一些数据库的巡检，你应该从哪几个方面去看或者去检查你的数据库。
　　主要有几个点可以让研发去做，通过巡检报告、可视化平台，可以推给研发相应的信息。比如像自增信息、表分区信息、慢查询，其实你可以发给他，由他们自己去做一些相应的调整。
　　作为DBA来说，最主要一点是要关注最后一条＂业务梳理＂，帮助研发梳理业务跟数据库之间到底是不是一个强依赖的关系，一个事务到底读写操作会有多少条，上下游逻辑是什么，能不能做熔断处理。一旦业务系统出现问题是否会影响别人的系统，这些需要DBA做检查。
　　再一个就是硬件和机房的巡检，我们在大促过程中主要出的问题可能硬件比较多，硬件出的问题最多的就是磁盘和Raid卡，经常Raid充放电的一瞬间可能会让数据库卡顿几秒钟甚至半分钟，如果这种情况在大促的时候出现那就是灾难级的。
　　最后做一个总结，不管你前面做了什么样的准备，这六点是你在大促之前必须要关注的。
　　容灾切换演练。高可用体系运行是否正常，同机房的切换、跨机房的切换是不是能够很好的运转，要通过大促之前的容灾切换演练寻求验证；
　　性能优化。通过研发视角可能会做一些相应的优化，DBA应该从一个管控的视角看一下这些优化是否是合理的；
　　压测方案。我们每年都会在大促之前做集团级别的军演，整个集团，整个业务链条会做一次这样的压测，然后通过压测去暴露各个业务条线、各个系统的峰值压力，比如我们最多能扛多大的峰值压力；
　　数据治理。我们的数据不是说越多越好，我们可以做一些数据的分离，包括我们在读写的时候也要加入MQ的思想或者缓存的思想，保证我们读写在数据库这一层都是相对来说是平稳的；
　　资源管控。不是所有的公司都像国企那样那么有钱，他们在使用服务器资产的时候还是非常谨慎的。我们要梳理每台机器的使用率，到底需不需要扩容或者缩容，这些需要在大促之前做一个充分的判断，因为在大促的时候有很多服务或者很多业务需要扩容，需要机器资源，这个时候就需要合理地把资源分配好；
　　业务优化。要减少每一个事务交互的次数，减少事务的逻辑，要做业务熔断的降级预案。尤其是连接池，这个也是在大促的时候经常发生的这么一个问题，大促那一瞬间数据连接满了，很多情况是因为业务层面的连接池过大，所以大家需要从这些点上去准备我们的大促。
　　>>>>
　　Q&A
　　Q1：因为我们做主从数据库，数据库我们会有一个平台扩容，扩容的时候因为数据量特别大，导致扩容时间特别长，您有什么建议？
　　A1：扩容应该在切换之前对业务访问性能不造成影响。比如你一个库要去做一拆二的这种水平拆分，这个时候你应该把数据从一个主库上面迁移到两个节点上，这个过程中首先你的数据同步相对来说要可控，不能非常暴力的从主库拉取数据，要注意io和并发压力。二是当你把全量的数据和增量的数据都能够追平的时候，要选择合适的时间做业务的切换，这样的话其实就能够把业务的影响降到最低。好多分布式数据库是弹性扩容的，这个弹性是怎么来的？其实就是悄悄的做数据搬移，它是不影响业务的。
　　Q2：您对数据库的容器化怎么看？
　　A2：这个问题非常好，因为京东商城应该是大规模使用数据库容器的一个案例。首先容器化还是分场景的。举个例子，在商城是大规模使用容器化，但是在数科，这个容器化的程度非常低。为什么？因为数科是跟支付，跟金融相关的，大部分还是跑在物理机上面，能不能使用容器化还是要看数据库的规模和体量以及业务场景。
　　Q3：京东数科这么大的数据库，在什么时候去做分库分表？
　　A3：这个问题也非常好，其实这个没有一个非常标准的答案，在我们公司，我们会有一个基本的界定，单表五千万。如果超过五千万，DBA主动会去联系研发沟通性能问题和水平拆分事宜。还有一种情况是研发在业务使用中，他已经感知业务响应时长不能够满足业务的请求的时候，他会主动来找到DBA。如果我们通过一系列的优化，一系列的调整还是不能满足它的业务要求的时候，其实我们也会去帮他做水平拆分。
　　Q4：如果我们在一些想做数据库备份，想做备份恢复可能只有前面两条，您这边对于这方面有没有别的方面考虑？
　　A4：备份恢复确实很头疼，尤其是数据量大的时候。我们应该怎么做？备份存储需要分级，如果真的需要恢复数据的话，肯定是从本地磁盘获取备份，这个数据恢复起来的快一点，因为可以减少网络的传输。另外一点其实我们也有一个方案就是我们所有的备份要每个季度内完成一次备份恢复，要去做备份有效性的检查。很多时候恢复的这份数据库其实就可以帮助到你快速找回数据，比如你想要通过恢复找数据，其实这个本分可能会在前几天的有效性检测的恢复中恢复好了一份数据。
　　Q5：刚才您说您这边是没有进行容器化的，我理解您是怎么解决比如说单节点应该不止一个实例，如果多实例会不会互相存在制约？
　　A5：我们现在确实就用单机多实例的方式去做的，我们做选型的时候，比如说资源隔离的这件事。目前来说不会有特别好的办法，我们现在最有效的就是把磁盘不会做成一个大的Raid组，进行io隔离，然后用cgroup做cpu mem和网络的隔离。
　　Q6：那如果A业务导到B业务，出现了这个问题，A资源响应特别高，影响B的数据库。
　　A6：那基本上就会迁移，我们能够把它放在单机多实例里面的理由就是它的业务量都非常小，如果出现像您刚才说的这种情况，要么通过优化的方案把压力降下去，要么就是把业务迁移走，因为有可能它真的不适合再用单机多实例的能力了。