暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

技术分享 | MySQL Shell 收集 MySQL 诊断报告(上)

452

作者:杨涛涛

资深数据库专家,专研 MySQL 十余年。擅长 MySQL、PostgreSQL、MongoDB 等开源数据库相关的备份恢复、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生,为各大运营商及银行金融企业提供 MySQL 相关技术支持、MySQL 相关课程培训等工作。

本文来源:原创投稿

* 爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。

通常对于 MySQL 运行慢、异常运行等等现象,需要通过收集当时的诊断报告以便后期重点分析并且给出对应解决方案,目前收集诊断报告的方法大致有以下几类:
  1. 手动写脚本收集。
  2. Percona-toolkit 工具集里自带的 pt-stalk 。
  3. MySQL 的 sys 库自带存储过程 diagnostics 。
  4. MySQL Shell 工具的 util 组件(需升级到 MySQL 8.0.31 最新版才能体验全部诊断程序)
这些工具基本上都可以从不同维度收集 OS 以及 MySQL SERVER 的诊断数据,并且生成对应的诊断报告。今天我们来介绍 MySQL Shell 最新版本 8.0.31 的 util 组件带来的全新诊断报告收集功能。

util 组件的诊断程序是由 debug 属性自带的几个内置函数实现的。目前有三个诊断函数:

  1. collect_diagnostics 用来收集MySQL单实例、副本集、InnoDB Cluster 的诊断数据。旧版本8.0.30 也可以用,不过功能不是很全面
  2. collect_high_load_diagnostics 用来循环多次收集,并找出负载异常的诊断数据。
  3. collect_slow_query_diagnostics 用来对函数 collect_diagnostics 收集到的慢日志做进一步分析。
今天我们先来介绍第一个函数 collect_diagnostics 如何使用:
函数 collect_diagnostics 用来收集如下诊断数据并给出对应诊断报告:
  1. 无主键的表
  2. 死索引的表
  3. MySQL 错误日志
  4. 二进制日志元数据
  5. 副本集状态(包含主库和从库)
  6. InnoDB Cluster 监控数据
  7. 表锁、行锁等数据
  8. 当前连接会话数据
  9. 当前内存数据
  10. 当前状态变量数据
  11. 当前 MySQL 慢日志(需主动开启开关)
  12. OS 数据(CPU、内存、IO、网络、MySQL 进程严重错误日志过滤等)
函数 collect_diagnostics 有两个入参:一个是输出路径;另一个是可选字典配置选项,比如可以配置慢日志收集、定制执行 SQL 语句、定制执行 SHELL 命令等等。

以下是常用调用示例:

  1. 只传递参数1,指定诊断数据打包输出路径,诊断报告会整体打包为 tmp/cd1.zip 。
util.debug.collect_diagnostics('/tmp/cd1')

  1. 激活慢日志抓取(必需条件:MySQL 慢日志开关开启、日志输出格式为 TABLE),诊断报告会整体打包为 tmp/cd2.zip ,并且包含慢日志诊断报告。
util.debug.collect_diagnostics('/tmp/cd2',{"slowQueries":True})

  1. 定制执行 SQL :收集预置诊断报告同时也收集指定的 SQL 语句执行结果。
util.debug.collect_diagnostics('/tmp/cd3',{"customSql":["select * from ytt.t1 order by id desc limit 100"]})

  1. 定制执行 SHELL 命令:收集预置诊断报告同时也收集指定的 SHELL 命令执行结果。
util.debug.collect_diagnostics('/tmp/cd4',{"customShell":["ps aux | grep mysqld"]})

  1. 收集所有成员诊断数据(副本集或者 InnoDB Cluster)。
util.debug.collect_diagnostics('/tmp/cd5',{"allMembers":True})

分别执行以上5条命令,在 tmp 目录下会生成如下文件:以下5个打包文件即是我们运行的5条命令的结果。

root@ytt-pc:/tmp# ll cd*
-rw------- 1 root root  893042 1月   5 10:31 cd1.zip
-rw------- 1 root root  818895 1月   5 10:55 cd2.zip
-rw------- 1 root root  819183 1月   5 11:02 cd3.zip
-rw------- 1 root root  835387 1月   5 11:06 cd4.zip
-rw------- 1 root root 2040913 1月   5 11:31 cd5.zip

要查看具体诊断报告,得先解压这些文件。先来看下 cd2.zip 解压后的内容:对于收集的诊断数据,有 tsv 和 yaml 两种格式的报告文件,报告文件以数字0开头,表示这个诊断报告来自一台单实例 MySQL 。

root@ytt-pc:/tmp/cd/cd2# ls|more
0.error_log
0.global_variables.tsv
0.global_variables.yaml
0.information_schema.innodb_metrics.tsv
0.information_schema.innodb_metrics.yaml
0.information_schema.innodb_trx.tsv
0.information_schema.innodb_trx.yaml
0.instance
0.metrics.tsv
0.performance_schema.events_waits_current.tsv
0.performance_schema.events_waits_current.yaml
0.performance_schema.host_cache.tsv
0.performance_schema.host_cache.yaml
0.performance_schema.metadata_locks.tsv
0.performance_schema.metadata_locks.yaml
...

比如查看此实例的连接字符串:

root@ytt-pc:/tmp/cd/cd2# cat 0.uri 
mysql://root@localhost:3306

以下为对应的慢日志报告:分别为慢日志数据、95分位慢日志数据以及根据扫描行数排序的慢日志数据。

root@ytt-pc:/tmp/cd/cd2# ls *slow*
0.slow_log.tsv 0.slow_queries_in_95_pctile.tsv 0.slow_queries_summary_by_rows_examined.tsv
0.slow_log.yaml 0.slow_queries_in_95_pctile.yaml 0.slow_queries_summary_by_rows_examined.yaml

cd1.zip 、cd2.zip 、cd3.zip 、cd4.zip 都是基于单实例收集的诊断报告,解压后的文件都是以0开头;cd5.zip 是基于副本集收集的诊断报告,解压后的文件是以1,2,3开头,分别代表实例3310,3311,3312。

比如查看副本集里3个成员的连接字符串:

root@ytt-pc:/tmp/cd/cd5# cat {1,2,3}.uri
mysql://root@127.0.0.1:3310?ssl-mode=required
mysql://root@127.0.0.1:3311?ssl-mode=required
mysql://root@127.0.0.1:3312?ssl-mode=required

目前副本集的拓扑:3310 为主,3311,3312为从,可以在主库上执行 show replicas 命令得到从库列表。

 MySQL  localhost:3310 ssl  SQL > show replicas;
+------------+-----------+------+------------+--------------------------------------+
| Server_Id | Host | Port | Source_Id | Replica_UUID |
+------------+-----------+------+------------+--------------------------------------+
| 2736952196 | 127.0.0.1 | 3312 | 4023085694 | 0824a675-8ca9-11ed-a719-0800278da4ac |
| 3604736168 | 127.0.0.1 | 3311 | 4023085694 | 0526130e-8ca9-11ed-b797-0800278da4ac |
+------------+-----------+------+------------+--------------------------------------+
2 rows in set (0.0002 sec)

从诊断报告里查看实例 3310 的从库列表:

root@ytt-pc:/tmp/cd/cd5# cat 1.SHOW_REPLICAS.yaml

...

#
Host: 127.0.0.1
Port: 3312
Replica_UUID: 0824a675-8ca9-11ed-a719-0800278da4ac
Server_Id: 2736952196

Source_Id: 4023085694
---

Host: 127.0.0.1
Port: 3311
Replica_UUID: 0526130e-8ca9-11ed-b797-0800278da4ac
Server_Id: 3604736168
Source_Id: 4023085694

结语:

MySQL Shell 8.0.31 带来的增强版收集诊断报告功能,能更好的弥补 MySQL 在这一块的空缺,避免安装第三方工具,从而简化 DBA 的学习成本。

本文关键字:#MySQL Shell# #MySQL 诊断报告收集#


文章推荐:

一款功能全面的 MySQL Shell 插件

使用 SQL 语句来简化 show engine innodb status 的结果解读

OceanBase 在 Ubuntu 平台部署

关于SQLE

爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者,支持多场景审核,支持标准化上线流程,原生支持 MySQL 审核且数据库类型可扩展的 SQL 审核工具。

SQLE 获取
类型地址
版本库https://github.com/actiontech/sqle
文档https://actiontech.github.io/sqle-docs-cn/
发布信息https://github.com/actiontech/sqle/releases
数据审核插件开发文档https://actiontech.github.io/sqle-docs-cn/3.modules/3.7_auditplugin/auditplugin_development.html

提交有效pr,高质量issue,将获赠面值200-500元(具体面额依据质量而定)京东卡以及爱可生开源社区精美周边!

更多关于 SQLE 的信息和交流,请加入官方QQ交流群:637150065...

文章转载自爱可生开源社区,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论