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
同步状态又恢复一致了。