如何实时监控MySql状态

如何实时监控MySql状态,第1张

首先介绍下 pt-stalk,它是 Percona-Toolkit 工具包中的一个工具,说起 PT 工具包大家都不陌生,平时常用的 pt-query-digest、 pt-online-schema-change 等工具都是出自于这个工具包,这里就不多介绍了。

pt-stalk 的主要功能是在出现问题时收集 OS 及 MySQL 的诊断信息,这其中包括:

1. OS 层面的 CPU、IO、内存、磁盘、网络等信息;

2. MySQL 层面的行锁等待、会话连接、主从复制,状态参数等信息。

而且 pt-stalk 是一个 Shell脚本,对于我这种看不懂 perl 的人来说比较友好,脚本里面的监控逻辑与监控命令也可以拿来参考,用于构建自己的监控体系。

三、使用

接着我们来看下如何使用这个工具。

pt-stalk 通常以后台服务形式监控 MySQL 并等待触发条件,当触发条件时收集相关诊断数据。

触发条件相关的参数有以下几个:

function:

∘ 默认为 status,代表监控 SHOW GLOBAL STATUS 的输出;

∘ 也可以设置为 processlist,代表监控 show processlist 的输出;

variable:

∘ 默认为 Threads_running,代表 监控参数,根据上述监控输出指定具体的监控项;

threshold:

∘ 默认为 25,代表 监控阈值,监控参数超过阈值,则满足触发条件;

∘ 监控参数的值非数字时,需要配合 match 参数一起使用,如 processlist 的 state 列;

cycles:

∘ 默认为 5,表示连续观察到五次满足触发条件时,才触发收集;

连接参数:host、password、port、socket。

其他一些重要参数:

iterations:该参数指定 pt-stalk 在触发收集几次后退出,默认会一直运行。

run-time:触发收集后,该参数指定收集多长时间的数据,默认 30 秒。

sleep:该参数指定在触发收集后,sleep 多久后继续监控,默认 300 秒。

interval:指定状态参数的检查频率,判断是否需要触发收集,默认 1 秒。

dest:监控数据存放路径,默认为 /var/lib/pt-stalk。

retention-time :监控数据保留时长,默认 30 天。

daemonize:以后台服务运行,默认不开启。

log:后台运行日志,默认为 /var/log/pt-stalk.log。

collect:触发发生时收集诊断数据,默认开启。

∘ collect-gdb:收集 GDB 堆栈跟踪,需要 gdb 工具。

∘ collect-strace:收集跟踪数据,需要 strace 工具。

∘ collect-tcpdump:收集 tcpdump 数据,需要 tcpdump 工具。

本期我们用 MySQL 提供的 DBUG 工具来研究 MySQL 的 SQL 处理流程。

起手先造个实例

这里得稍微改一下实例的启动文件 start,将 CUSTOM_MYSQLD 改为 mysqld-debug:

重启一下实例,加上 debug 参数:

我们来做一两个实验,说明 DBUG 包的作用:

先设置一个简单的调试规则,我们设置了两个调试选项:

d:开启各个调试点的输出

O,/tmp/mysqld.trace:将调试结果输出到指定文件

请点击输入图片描述

然后我们创建了一张表,来看一下调试的输出结果:

请点击输入图片描述

可以看到 create table 的过程中,MySQL 的一些细节 *** 作,比如分配内存 alloc_root 等

这样看还不够直观,我们增加一些信息:

请点击输入图片描述

来看看效果:

请点击输入图片描述

可以看到输出变成了调用树的形式,现在就可以分辨出 alloc_root 分配的内存,是为了解析 SQL 时用的(mysql_parse)

我们再增加一些有用的信息:

请点击输入图片描述

可以看到结果中增加了文件名和行号:

请点击输入图片描述

现在我们可以在输出中找一下统计表相关的信息:

请点击输入图片描述

可以看到 MySQL 在这里非常机智,直接执行了一个内置的存储过程来更新统计表。

沿着 que_eval_sql,可以找到其他类似的统计表,比如下面这些:

请点击输入图片描述

请点击输入图片描述

本次实验中,我们借助了 MySQL 的 DBUG 包,来让 MySQL 将处理过程暴露出来。MySQL 中类似的技术还有不少,比如 performance_schema,OPTIMIZER_TRACE 等等。

这些技术将 MySQL 的不同方向的信息暴露出来,方便大家理解其中机制。

1、增加一个用户同步使用的帐号:

GRANT FILE ON *.* TO ‘backup’@'10.10.8.112' IDENTIFIED BY ‘1234’

GRANTREPLICATION SLAVE ON *.* TO ‘backup’@'10.10.8.112' IDENTIFIED BY ‘1234’

赋予10.10.8.112也就是Slave机器有File权限,只赋予Slave机器有File权限还不行,还要给它REPLICATION SLAVE的权

限才可以。

2、增加一个数据库作为同步数据库:

create databbse test

3、创建一个表结构:

create table mytest (username varchar(20),password varchar(20))

4、修改配置文件:

修改A的/etc/my.cnf文件,在my.cnf配置项中加入下面配置:

server-id = 1 #Server标识

log-bin

binlog-do-db=test #指定需要日志的数据库

5、重起数据库服务:

service mysqld restart

查看server-id:

show variable like ‘server_id’;

实例:

mysql>show variables like 'server_id'

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| server_id | 1 |

+---------------+-------+

1 row in set (0.00 sec)

6、用show master status/G命令看日志情况。

正常为:

mysql>show master status/G


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/7544120.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-06
下一篇 2023-04-06

发表评论

登录后才能评论

评论列表(0条)

保存