mysql运维工具-----percona-toolkit

Percona工具包文档Percona Toolkit是Percona（http://www.percona.com/） 支持人员使用的高级命令行工具的集合，用于执行各种MySQL和系统任务，这些任务太难或难以手动执行。这些工具是私有或“一次性”脚本的理想替代品，因为它们是专业开发，正式测试和完整记录的。它们也是完全独立的，因此安装快速简便，无需安装库。 
Percona Toolkit源自Maatkit和Aspersa，这两个最着名的MySQL服务器管理工​​具包。它由Percona开发和支持。有关Percona开发的更多信息和其他免费开源软件，请访问http://www.percona.com/software/。 

工具类别汇总说明(引用：http://blog.51cto.com/lookingdream/2067218)

工具命令	工具作用	备注
开发类	pt-duplicate-key-checker	列出并删除重复的索引和外键
	pt-online-schema-change	在线修改表结构
	pt-query-advisor	分析查询语句，并给出建议，有bug 已废弃
	pt-show-grants	规范化和打印权限
	pt-upgrade	在多个服务器上执行查询，并比较不同
性能类	pt-index-usage	分析日志中索引使用情况，并出报告
	pt-pmp	为查询结果跟踪，并汇总跟踪结果
	pt-visual-explain	格式化执行计划
	pt-table-usage	分析日志中查询并分析表使用情况 pt 2.2新增命令
配置类	pt-config-diff	比较配置文件和参数
	pt-mysql-summary	对mysql配置和status进行汇总
	pt-variable-advisor	分析参数，并提出建议
监控类	pt-deadlock-logger	提取和记录mysql死锁信息
	pt-fk-error-logger	提取和记录外键信息
	pt-mext	并行查看status样本信息
	pt-query-digest	分析查询日志，并产生报告 常用命令
	pt-trend	按照时间段读取slow日志信息 已废弃
复制类	pt-heartbeat	监控mysql复制延迟
	pt-slave-delay	设定从落后主的时间
	pt-slave-find	查找和打印所有mysql复制层级关系
	pt-slave-restart	监控salve错误，并尝试重启salve
	pt-table-checksum	校验主从复制一致性
	pt-table-sync	高效同步表数据
系统类	pt-diskstats	查看系统磁盘状态
	pt-fifo-split 模	拟切割文件并输出
	pt-summary	收集和显示系统概况
	pt-stalk	出现问题时，收集诊断数据
	pt-sift	浏览由pt-stalk创建的文件 pt 2.2新增命令
	pt-ioprofile	查询进程IO并打印一个IO活动表 pt 2.2新增命令
实用类	pt-archiver	将表数据归档到另一个表或文件中
	pt-find	查找表并执行命令
	pt-kill	Kill掉符合条件的sql 常用命令
	pt-align	对齐其他工具的输出 pt 2.2新增命令
	pt-fingerprint	将查询转成密文 pt 2.2新增命令

汇总目录官方文档地址： 
https://www.percona.com/doc/percona-toolkit/2.2/index.html

 

锦囊妙计一：

pt-online-schema-change

功能可以在线整理表结构，收集碎片，给大表添加字段和索引。避免出现锁表导致阻塞读写的操作。针对 MySQL 5.7 版本，就可以不需要使用这个命令，直接在线 online DDL 就可以了。

锦囊妙计二：

pt-query-digest 

功能：现在捕获线上TOP 10 慢 sql 语句。

 

大家都知道数据库大多数的性能问题是 sql 语句造成的，所以我们要抓住它们这些犯罪分子。及时做相关的优化处理。

 

展现过程如下：

可以根据时间间隔，来采样慢 sql 语句。since 是可以调整的 sql 语句

[root@node3 bin]# ./pt-query-digest --since=24h /data/mysql/slow.log > 1.log

查看 sql 报告，总结慢语句有哪些，并可以看针对时间的消耗。

锦囊妙计三：

pt-heartbeat

功能监控主从延迟。监控从库落后主库大概多少时间。

环境介绍：192.168.56.132主库，192.168.56.133从库

 

操作如下：

在主库上执行：

[root@node3 bin]# ./pt-heartbeat --database test --update 

–create-table --daemonize -uroot -proot123

• 1

test为我监控同步的库，在该库下创建一张监控表heartbeat，后台进程会时时更新这张表。

 

在从库上执行监控主从同步延迟时间的语句：

master-server-id是主库的server-id, -h（主库ip）

[root@node4 bin]# ./pt-heartbeat --master-server-id=1323306

–monitor --database test  -uzs -p123456 -h 192.168.56.132

0.00s [  0.00s,  0.00s,  0.00s ]

0.00s [  0.00s,  0.00s,  0.00s ]

0.00s [  0.00s,  0.00s,  0.00s ]

0.00s [  0.00s,  0.00s,  0.00s ]

0.00s [  0.00s,  0.00s,  0.00s ]

0.00s [  0.00s,  0.00s,  0.00s ]

时间是0s，目前没有延迟的出现。

锦囊妙计四：

pt-table-checksum

功能检查主从复制一致性

原理：在主上执行检查语句去检查 mysql主从复制的一致性，生成 replace 语句，然后通过复制传递到从库，再通过update 更新 master_src 的值。最后通过检测从上 this_src 和 master_src 的
值从而判断复制是否一致。

比较test库的差异情况，在主库上面执行：[root@node3 bin]# ./pt-table-checksum --no-check-binlog-format --nocheck-replication-filters

–databases=test --replicate=test.checksums --host=192.168.56.132 -uzs -p123456

TS ERRORS  DIFFS     ROWS  CHUNKS SKIPPED    TIME TABLE

08-10T16:01:02      0      0        1       1       0   0.013 test.heartbeat

08-10T16:01:02      0      0        0       1       0   0.015 test.su

08-10T16:01:02      0      0        0       1       0   0.011 test.t

可见diff都为0，证明主从的test库没有差异情况。

比较test库哪些表有差异(需要添加replicate-check-only)，在主库上面执行：

[root@node3 bin]# ./pt-table-checksum --no-check-binlog-format 

–nocheck-replication-filters --databases=test --replicate=test.checksums

–replicate-check-only  --host=192.168.56.132 -uzs -p123456

Differences on node4

TABLE CHUNK CNT_DIFF CRC_DIFF CHUNK_INDEX LOWER_BOUNDARY UPPER_BOUNDARY

test.t 1 1 1

可见test库下面t这张表主从数据不一致。

 

锦囊妙计五：

pt-slave-restart

功能：监控主从错误，并尝试重启MySQL主从

注意事项：跳过错误这个命令，解决从库多数据的现象（错误代码1062）。如果从库少数据，还跳过错误，就不能从根儿上解决主从同步的问题了（错误代码1032），就需要先找到缺少的数据是什么了，如果缺少的特别多，建议重新搭建主从环境。

 

从库出现1062的错误：

Slave_IO_Running: Yes

Slave_SQL_Running: No

Last_Errno: 1062

Last_Error: Could not execute Write_rows event on table test.t;

Duplicate entry ‘1’ for key ‘PRIMARY’,

Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY;

the event’s master log mysql-bin.000006, end_log_pos 757482

 

需要在从库上面执行：

[root@node4 bin]# ./pt-slave-restart -uroot -proot123 --error-numbers=1062

2017-08-10T16:28:12 p=….,u=root node4-relay-bin.000002      751437 1062

 

跳过错误之后，检查主从结果：

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

同步状态又恢复一致了。