美团 MySQL 数据库巡检系统的设计与应用

说明

作者：王琦

来源：美团技术团队

我们生活中随处可见各种巡检系统，比如电力巡检、消防检查等，正是这些巡检工作，我们才能在稳定的环境下进行工作、生活。巡检对于数据库或者其他 IT 系统也非常重要，特别是在降低风险和提高服务稳定性方面。

一、背景

以下核心功能组件必须保证数据库的稳定运行：

图1 核心功能组件的数据库运维

其中，数据库检查作为运维保障体系中最重要的环节之一，可以帮助我们发现数据库存在的隐患，提前处理，防患于未然。对于大型集群来说，灵活强大的自动检查能力非常重要。

任何系统都将经历一个原始阶段。最早的检查由中控机 定期检查脚本 前端显示组成。然而，随着时间的推移，旧的检查计划逐渐暴露出一些问题：

定期检查任务的执行依赖于中央控制机，存在单点问题；检查结果分散在不同的库表中，无法统计；检查脚本没有统一的开发标准，不能保证实施的成功率；每个检查项目需要单独编写接口以获取数据，并修改检查结果显示的前端，更麻烦；检查发现的隐患需要 DBA 主动打开前端检查，然后处理，影响整体隐患的治理速度；……

因此，我们需要一个灵活稳定的检查系统来帮助我们解决这些痛点，确保数据库的稳定性。

二、设计原则

巡检系统的设计原则，我们从以下三个方面进行考虑：

稳定性 ：巡逻作为保证数据库稳定的工具，必须保证自身的稳定性；高效 ：以用户为中心，尽量简化复杂性，降低用户使用成本，使新生能够快速控制和管理隐患；提高新的检查部署效率，随着结构、版本、基本模块等运行维护环境的变化，新的检查需求源源不断地涌现，更快的部署等于更早的保证；可操作 ：以数据为基础，运行隐患，包括促进隐患控制、检查治理效率、趋势、弱点等。3、系统架构

美团 MySQL 数据库检查系统的架构图设计如下所示。接下来，我们将简要介绍检查系统的主要模块，从下到上。

图片 2 美团 MySQL

1. 执行层

检查执行环境 :由多台检查执行机构组成，检查任务脚本同时部署在所有执行机构上。执行机会定期从检查 Git 仓库提取最新脚本，使用 Python Virtualenv Git 管理，方便扩展新的执行器。任务调度 ：美团基础设施部开发的分布式定时任务系统 Crane 调度，解决传统定时任务单点问题。Crane 将随机指定执行机器执行任务。如果执行机器出现故障，将指定其他执行机器重新执行任务。一般来说，检查任务对应于检查项目。检查任务将根据一定的规则判断特定的检查目标是否存在隐患。检查目标 ：除生产数据库外，还将检查数据库周围的高可用组件、中间部件等产品，尽可能覆盖所有会导致数据库故障的风险点。

2. 存储层

检查数据库：主要用于保存检查相关数据。为了规范和简化流程，我们将检查中发现的隐患保存在数据库中，并提供一般的存储函数，可以实现以下功能：

自动补充隐患负责人、隐患发现时间等信息；仓储操作权力等。；支持半结构化检查结果，不同的检查结果包括不同的属性，如检查 A 隐患有中间件类型B 有主库 CPU 核数，以上不同结构的数据可分析入库；对于表粒度的隐患，如果分库分表有隐患，会自动合并成逻辑表隐患入库。

巡检脚本 Git 仓库 :用于管理检查脚本。为方便 DBA 增加了检查。在系统建设过程中，我们增加了多个公共功能，以降低开发新检查的成本，方便将旧检查脚本转移到新系统。

3. 应用层

**集成到数据库运维平台 **：作为隐患详细显示、配置检查显示、管理白名单等功能的入口。为提高隐患治理效率。我们做了以下设计。

隐患细节显示页面将标记每个隐患的天数，以便跟踪隐患的原因。在配置新的检查显示器时，必须同时制定隐患解决方案，以确保隐患治理有序，避免错误的治理方法导致错误。

该模块的主要目的是促进隐患的治理。

操作报告帮助管理者从全球角度掌握隐患治理的进展，包括隐患趋势、股票分布、增量分布、平均治理周期等核心内容，从上到下促进隐患治理；报告数据也通过 Crane 计算获得定时任务。= 隐患控制催办功能用于监督 DBA 处理隐患。催促内容将包括隐患的具体内容、发生时间、处理方案等。催促形式包括大象新闻和报警。根据检查的关键程度，可以选择哪种形式进行相应的配置。

外部数据服务 ：主要是将巡检隐患数据提供给美团内部其他平台或项目使用，让巡检数据发挥更大的价值。

美团 对接先知平台SRE 团队开发主要面向R&D人员(以下简称 RD）对于用户的风险发现和运营平台，平台接收各服务提供商报告的隐患数据RD 从组织结构维度展示每项服务的风险点，并跟进 RD 处理进度。检查系统将要求 RD 参与治理的隐患，如大表、无独特键表等，借助先知平台推送给 RD 治理。运维周报主要面向业务线 RD 负责人和业务线 DBA，以静态报告的形式显示业务线数据库的运行和存在的问题，检查隐患是报告的内容之一。4、检查项目

检查项目按负责人分为 DBA 和 RD，DBA 主要负责处理影响服务稳定性的数据库基本功能组件和隐患。RD 主要负责库表设计缺陷、数据库使用不规范造成的业务故障或性能问题。还有需要他们同时参与治理的检查项目，如磁盘可用空间预测。目前，检查项目共 ** 个，类别分布如下图所示：

图片 3 巡检项目分布

集群 :主要检查集群拓扑、核心参数等隐患；机器 :主要检查服务器硬件隐患；Sche ** /SQL :检查表结构设计，数据库使用，SQL 质量隐患；高可用 / 备份 / 中间件 / 报警 :主要检查相关核心功能组件是否存在隐患。

下面，我们通过列出几项检查任务来简要说明检查项目：

五、成果

美团 MySQL 检查系统已稳定运行近一年，基于新的检查系统启动的检查项目 49 。通过检查系统的持续运行，在团队的共同努力下，我们控制了 800 的核心隐患。近 3 隐患治理周期平均不超过 4 天，隐患总数保持在极小的数量级，有效保证了数据库的稳定性。

图 4 隐患操作 - 团队中虚拟小组隐患的平均治疗周期

以下隐患趋势图显示了近一年隐患数量，由于新的检查项目启动，数量突然增加。从总体趋势来看，隐患库存大幅下降。

图 5 隐患操作 - 隐患总量趋势

除了促进内部隐患的治理外，我们还过对接先知平台积极推广 RD 隐患控制量超过5000 。

图 6 对接先知 - 推动 RD 治理隐患

为了提高用户体验，我们还投入了提高准确性的关键投资，使每次检查在上线前都能进行严格的测试和验证。

比较其他先知接入方，DBA 报告的隐患在总量、转化率和反馈率方面处于较高水平。可以看出，我们报告的隐患风险也得到了 RD 的认可。

图片 7 对接先知 - 各接入方报告隐患

指标说明：

反馈率 = 截至目前时刻反馈的风险事件数量 / 截至目前时刻产生的风险事件总量 * 100%；反馈准确率 = 截至目前时刻准确反馈的风险事件数量 / 截至目前时刻反馈的风险事件总量 * 100%；转化率 = 截至目前，用户反馈准确，需要处理的风险事件数量 / 截至目前，风险事件总量 * 100%

除继续完善补充巡检项目外，未来巡检系统还将继续探索以下方向的迭代：

提高自动化能力，提高 CI 和审计；加强操作能力，进一步细化各隐患的重要性，优先协助决策和治理；自动修复隐患。推荐阅读：

为什么一线大厂面试要问分布式？

在一次又一次的失败中，我总结了这万字《MySQL性能调优笔记

并发编程详细说明:从理论基础到案例实战，十三种工具，十种设计模式