Percona Toolkit

技术分享 | MySQL 监控利器之 Pt-Stalk

我们两清 提交于 2020-10-15 07:07:53
作者:xuty 本文来源:原创投稿 *爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 一、概述 之前在社区发了一篇 故障分析 | 有效解决 MySQL 行锁等待超时问题 文档,主要介绍了下行锁超时的监控方法,下方评论中有人提到了 pt-stalk 工具也可以监控行锁超时,因为个人没怎么用过这个工具,所以下意识的就去 google 了一下。因为没找到有介绍具体监控输出的文档,就以为这个工具没法监控行锁等待,最后果断被打脸了。 以上是个小插曲,个人在本地测试了下 pt-stalk 的监控输出后,发现其监控项远远比我预测的多,用起来也比较方便,所以在这里分享下这个工具。 二、介绍 首先介绍下 pt-stalk ,它是 Percona-Toolkit 工具包中的一个工具,说起 PT 工具包大家都不陌生,平时常用的 pt-query-digest 、 pt-online-schema-change 等工具都是出自于这个工具包,这里就不多介绍了。 pt-stalk 的主要功能是 在出现问题时收集 OS 及 MySQL 的诊断信息 ,这其中包括: OS 层面的 CPU、IO、内存、磁盘、网络等信息; MySQL 层面的行锁等待、会话连接、主从复制,状态参数等信息。 而且 pt-stalk 是一个 Shell 脚本 ,对于我这种看不懂 perl 的人来说比较友好

mysql大表在不停机的情况下增加字段该怎么处理

≡放荡痞女 提交于 2020-08-16 16:59:40
MySQL中给一张千万甚至更大量级的表添加字段一直是比较头疼的问题,遇到此情况通常该如果处理?本文通过常见的三种场景进行案例说明。 1、 环境准备 数据库版本 : 5.7.25-28(Percona 分支) 服务器配置: 3台centos 7虚拟机,配置均为2CPU 2G内存 数据库架构: 1主2从的MHA架构(为了方便主从切换场景的演示,如开启GTID,则两节点即可),关于MHA搭建可参考此文 MySQL高可用之MHA集群部署 准备测试表: 创建一张2kw记录的表,快速创建的方法可以参考 快速创建连续数 本次对存储过程稍作修改,多添加几个字段,存储过程如下: DELIMITER $$ CREATE PROCEDURE `sp_createNum`(cnt INT ) BEGIN DECLARE i INT DEFAULT 1 ; DROP TABLE if exists tb_add_columns; CREATE TABLE if not exists tb_add_columns(id int primary key ,col1 int ,col2 varchar ( 32 )); INSERT INTO tb_add_columns(id,col1,col2) SELECT i as id ,i % 7 as col1,md5(i) as col2; WHILE i <

mysql中的pt工具集

妖精的绣舞 提交于 2020-08-15 08:37:04
关键词:PT工具 【1】percona-toolkit 工具包 【1.1】percona-toolkit下载     下载地址:        https://www.percona.com/downloads/percona-toolkit/LATEST/     linux下载/windows直接点击下载 percona-toolkit-3.1.0_x86_64.tar.gz        https://www.percona.com/downloads/percona-toolkit/3.1.0/binary/tarball/percona-toolkit-3.1.0_x86_64.tar.gz 【1.2】percona-toolkit 安装 #(1)安装perl,需要本地或者网络yum源,参考: yum源配置 yum -y install perl-devel perl-Digest-MD5 perl-DBI perl-DBD-MySQL perl-IO-Socket-SSL.noarch perl-Time-HiRes #(2)编译安装 需求 * Perl v5.8 or newer * Bash v3 or newer * Core Perl modules like Time::HiRes # perl --version |head -2 #检查perl版本 #

mysql大表在不停机的情况下增加字段该怎么处理

落花浮王杯 提交于 2020-08-06 23:34:31
MySQL中给一张千万甚至更大量级的表添加字段一直是比较头疼的问题,遇到此情况通常该如果处理?本文通过常见的三种场景进行案例说明。 1、 环境准备 数据库版本 : 5.7.25-28(Percona 分支) 服务器配置: 3台centos 7虚拟机,配置均为2CPU 2G内存 数据库架构: 1主2从的MHA架构(为了方便主从切换场景的演示,如开启GTID,则两节点即可),关于MHA搭建可参考此文 MySQL高可用之MHA集群部署 准备测试表: 创建一张2kw记录的表,快速创建的方法可以参考 快速创建连续数 本次对存储过程稍作修改,多添加几个字段,存储过程如下: DELIMITER $$ CREATE PROCEDURE `sp_createNum`(cnt INT ) BEGIN DECLARE i INT DEFAULT 1 ; DROP TABLE if exists tb_add_columns; CREATE TABLE if not exists tb_add_columns(id int primary key ,col1 int ,col2 varchar ( 32 )); INSERT INTO tb_add_columns(id,col1,col2) SELECT i as id ,i % 7 as col1,md5(i) as col2; WHILE i <

mysql 消耗CPU 异常高

我的未来我决定 提交于 2020-05-08 13:58:16
1.这里看到的是 主机cpu 90% 都给消耗掉了,主要是mysql 进程消耗资源 top - 14:46:26 up 266 days, 20:41, 4 users, load average: 17.14, 15.68, 10.69 Tasks: 264 total, 1 running, 263 sleeping, 0 stopped, 0 zombie Cpu(s): 69.5%us, 21.2%sy, 0.0%ni, 9.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 16333448k total, 9920660k used, 6412788k free, 488896k buffers Swap: 2097148k total, 24448k used, 2072700k free, 3965104k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9386 mysql 20 0 14.6g 4.5g 9164 S 723.8 28.9 416:42.07 /db/mysql/app/mysql/bin/mysqld --defaults-file=/db/mysql/app/mysql/my.cnf --basedi 11846 root 20 0

mysql客户端报错:libmysqlclient_16 not defined in file libmysqlclient.so.16

江枫思渺然 提交于 2020-05-06 08:44:16
报错情况: 安装完mydumper之后( 上一篇文章 ),登陆Mysql客户端报错:version libmysqlclient_16 not defined in file libmysqlclient.so.16 with link time reference 同样:mysql的其他客户端都出现了同样的问题,比如:mysqladmin,mysqldumper等,但是mydumper却能正常使用! 很明显,这是库文件的连接出了问题,第一想法,是mydumper安装后什么包修改了这个原本正常的链接,上一篇文章(链接在上面)中有关Mysql的包只有mysql-devel,检查一下是不是这个mysql-devel修改了原有的参数 ldd $(which mysql) | grep mysql rpm -qf /usr/lib64/libmysqlclient.so.16 发现这个libmysqlclient.so.16 并没有在任何包中。 我最近使用可能会牵扯mysql的还有一个percona toolkit,会不会是这个原因呢? rpm -qa | grep Percona Percona-Server-shared-51-5.1.73-rel14.12.624.rhel6.x86_64 果然是这个percona-server,安装toolkit时图便宜,使用了yum

percona-toolki安装冲突(my.cnf Percona-Server-shared与mysql-community-server)

只谈情不闲聊 提交于 2020-04-27 21:55:05
最近在安装percona-toolkit工具包时,提示在my.cnf文件中, Percona-Server-shared与mysql-community-server冲突。起初还以为是一定需安装Percona-Server-shared这样一个包才可以呢。Google了一下,原来是需要安装mysql-community-libs-compat 才可以搞定。下面是对这个问题展开描述。 1、故障现象 [root@centos7 ~]# yum install percona-toolkit -y Transaction check error: file /etc/my.cnf from install of Percona-Server-shared-56-5.6.40-rel84.0.el7.x86_64 conflicts with file from package mysql-community-server-5.7.23-1.el7.x86_64 2、本地环境检查 [root@centos7 ~]# more /etc/redhat-release CentOS Linux release 7.2.1511 (Core) [root@centos7 ~]# rpm -qa|grep -i mysql mysql-community-client-5.7.23-1.el7

MySQL 必备工具使用的6个锦囊妙计!

点点圈 提交于 2020-04-27 20:49:31
这款工具是 MySQL 一个重要分支 percona 的, 名称叫做 percona-toolkit(一把锋利的瑞士军刀), 它呢是一组命令的集合。今儿给大家介绍几个我们在生产环境中最长用到的。 工具包的下载地址:https://www.percona.com/downloads/percona-toolkit/LATEST/ 安装过程很简单,先解压: tar -zxvf percona-toolkit-3.0.3_x86_64.tar.gz 由于是二进制的包,解压完可以直接进到percona-toolkit-3.0.3/bin目录下使用。 锦囊妙计一: pt-online-schema-change 功能可以在线整理表结构,收集碎片,给大表添加字段和索引。避免出现锁表导致阻塞读写的操作。针对 MySQL 5.7 版本,就可以不需要使用这个命令,直接在线 online DDL 就可以了。 展现过程如下: 由于是测试环境,就不创建一张数据量特大的表,主要让大家理解这个过程。 这是表里面数据的情况和表结构 mysql> select count(*) from su; + ----------+ | count(*) | + ----------+ | 100000 | + ----------+ 1 row in set ( 0.03 sec) mysql> desc su; + -

MySQL慢查询分析工具pt-query-digest详解

Deadly 提交于 2020-04-27 20:05:28
一、简介 pt-query-digest是用于分析mysql慢查询的一个工具,它可以分析binlog、General log、slowlog,也可以通过SHOWPROCESSLIST或者通过tcpdump抓取的MySQL协议数据来进行分析。可以把分析结果输出到文件中,分析过程是先对查询语句的条件进行参数化,然后对参数化以后的查询进行分组统计,统计出各查询的执行时间、次数、占比等,可以借助分析结果找出问题进行优化。 二、安装pt-query-digest 1.下载页面: https://www.percona.com/doc/percona-toolkit/2.2/installation.html 2.perl的模块 yum install -y perl-CPAN perl-Time-HiRes 3.安装步骤 方法一:rpm安装 cd /usr/local/src wget percona.com/get/percona-toolkit.rpm yum install -y percona-toolkit.rpm 工具安装目录在:/usr/bin 方法二:源码安装 cd /usr/local/src wget percona.com/get/percona-toolkit.tar.gz tar zxf percona-toolkit.tar.gz cd percona

读薄《高性能MySql》(四)查询性能优化

强颜欢笑 提交于 2020-04-22 04:34:24
读薄《高性能MySql》(一)MySql基本知识 读薄《高性能MySql》(二)Scheme与数据优化 读薄《高性能MySql》(三)索引优化 读薄《高性能MySql》(四)查询性能优化 对 MySql 进行优化,必须对 Scheme,索引,查询语句一同优化。 通过前面的章节我们掌握了 Scheme 和 索引的优化,最后我们来看一下查询优化。 为了优化查询,我们必须先了解查询是怎样执行的,然后探讨优化器在哪些方面做得还不足,以帮助 MySql 更有效的执行查询。 #优化数据访问 在一条 Sql 语句执行的很慢的时候,可以从以下两个方面来分析: 是否在检索的时候访问了太多的行或者列 MySql 服务器是否在分析大量超过需要的行 请求了不需要的数据 ###万恶之源 SELECT * 一个很好用的观点就是在每次使用 SELECT * 取出全部行的时候都要审视一下自己是否需要全部数据。 取出所有列可能使得索引覆盖无效,一些 DBA 是严格禁止 SELECT * 的写法的。 重复查询数据 有些地方可能会不小心的重复查询了相同的数据。比如在论坛中,如果一个人回复多次,很有可能会一不小心每次都去请求这个人的资料,一个有效的方法就是使用缓存。 扫描额外的记录 确定查询只返回需要的数据以后,接下来该看一下为了返回需要的记录是否扫描了太多行了。有两个指标我们需要关注,一个是扫描的行数和返回行数的比值