MySQL业务巡检的一些梳理

这是学习笔记的第 1788篇文章

如果对MySQL做一些巡检，那么巡检工作该怎么做，当然我们可以想到内核参数，系统配置，数据库参数配置等。这些巡检工作其实对于业务同学来说，难以体现这样的关联，或者说得直白一些，业务同学会认为这是DBA应该做的事情。

那么业务同学关心哪些指标，我们的巡检是不是也可以换个方式来做，既能服务于业务，也能体现我们工作的深度和广度，这样一来，我们提供的就不是一个黑盒服务，而是可以转变为更加主动的自助服务了。

我把巡检的内容做了下归类，之前总结写了满满一大页，最后发现需要体现的信息太多，结果反而会有一种混乱的感觉，那么我们就需要提炼和简化，我把整体的信息分为了三个维度：系统，数据库和业务。

可以用一句简单的话来总结：这个服务器上的数据库服务对开发同学有没有什么建议？

系统信息包括以下的类别：

1. 主机信息
2. 监控信息
3. 报警信息
4. 网络信息
5. 防火墙信息

数据库信息包含了以下的类别：

1. 实例信息
2. 集群信息
3. 元数据变更历史
4. 备份信息

业务信息包含了以下的类别：

1. 应用信息
2. 数据库概要信息
3. 数据库用户
4. 数据库连接信息
5. 工单信息
6. 表信息
7. 索引信息
8. 慢日志信息

从信息的采集方式来说，也会分为几种途径：

1. 数据字典信息
2. 数据历史信息
3. 在线提取信息
4. 在线分析数据

大部分数据是通过数据字典的配置信息得到，而对于业务巡检来说，更有意义的便是后面三类信息的聚合。

通过后面三类信息的提取和聚合，能够根据设定的数据模型来发现一些潜在的问题。

对于系统巡检问题，主要是面向运维同学，需要作出响应和明确的处理方法，而对于业务同学而言，就是一种透明的处理方式，比如业务同学发现某个服务产生了问题，可以通过系统的配置信息和监控报警来确认是不是服务出现了问题。在这个时候他们可以主动提取这些信息，这就是一个自助服务的初衷。

对于数据库巡检，对于业务同学来说就是一种全新的补充，比如对于业务同学开放了VIP,但是实际业务中可能是一主多从的架构，那么业务同学就需要了解目前的架构方式，比如一主多从，那么就可以使用多个从库提供读写分离的服务，而不是仅仅告诉一个VIP就完事了。通过数据库信息的补充，能够减少业务处理中的更多确认环节，最起码业务同学提出一个需求就可以明确知道你们理解问题的维度是不是基本平衡。

对于业务巡检，这是整个巡检的核心任务，对于业务同学，他能够接触到的就是数据库，表和索引了，但是绝大多数情况下，业务同学压根不知道自己所处的环境是否存在问题，是否配置得当等。在权限允许的情况下，我们可以提供这样的自助服务来明确告诉业务同学这样做是有问题的，这样做是有风险的。这样做有几个好处，一种是由被动变为主动，主动发现问题主动提示，一般来说对于业务同学是一种相对友好的方式，远比出现问题被动处理要好得多。另外一种就是如果这个问题很严重，但是不好协调，我们可以通过专业报告的方式来提前告知，在多次提醒无效的情况下，如果出了问题，对DBA同学也是一种无形的保护。

当然在巡检中，我们需要恪守的一个标准就是让业务看得懂的巡检，既然要看得懂，我们就需要在可视化方面做一些工作，比如我们告诉业务同学CPU负载30%是有问题的，那么我们就不需要口头书面来告知，而是通过阈值设置的方式来告诉他们，他们一看曲线图，就大体知道这样有没有问题。在数字化之外的改进就是可视化的改进。