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

今天对慢日志模块做了一个初版的设计,整体上可以实现一个相对完整的慢日志周期管理。设计图如下:

整体上分了六个大的步骤,我简单解释一下:

慢日志切分:

对于目前的数据库环境来说,慢日志的管理是松散的,没有做到细粒度的管理模式。从规范标准的角度来说,希望慢日志是周期性的转储,需要我们对慢日志做周期性切分。

在此我们需要明确一个共识,那就是什么样的SQL属于慢日志,这里有几个参数需要内部明确下,比如SQL执行时间超过1秒我们指定为慢日志,如果没有使用索引,也归类到慢日志。

同时慢日志的导出和管理都是在主库端。

慢日志转储:

对收集的慢日志内容,我们需要统筹管理,比如有100套环境,那么我们可以指定一台慢日志服务器,通过通信管道比如rsync或者sftp等方式把慢日志内容同步到日志服务器,总体来说,慢日志的内容量和binlog完全不在一个量级,占用的空间要小很多。所以保留周期可以设定为2个星期,更早的日志信息可以下沉到HDFS里面。

慢日志分析:

以上两个步骤只是采集慢日志,不做慢日志的分析,到了日志服务器之后,应该是有日志服务器来统一解析,将解析的结果格式化,比如是json格式。提取出我们需要的一些关键内容。

慢日志SQL管理:

其实对于慢查询SQL是我们应该做细粒度的管理的,比如我们采集的安日志文件里面有一个查询语句,这个SQL之前是否出现过,之前的性能如何,这个通过现有的文件是无法获得的,就需要我们来对慢查询SQL实现细粒度管理,实现一个初步的生命周期管理。

这样一旦发现问题,我们也好定位在之前是否存在问题。

慢日志性能报警:

这属于一个锦上添花的功能,比如慢日志在半个小时内增长超过10M,那么我们可以认为是存在性能问题的,另外就是对慢日志的个数进行统计,如果X分钟超过了X个就触发报警。

慢日志报告提取:

对于慢日志的报告提取,可以分为两个维度。

对于运维来说,我们可以设立一个目标,慢日志排行榜。通过一个全局的排行榜来不断优化SQL,提高系统的整体性能和SQL水平。

对于业务同学来说,我们可以提供基于时间维度,对象维度的SQL慢日志信息提取,通过慢日志信息来同步获得一些性能信息,得到SQL的执行计划。

相关链接: