工具分享丨分析GreatSQL Binglog神器
|
在GreatSQL中,Binlog可以说是 GreatSQL 中比较重要的日志了,在日常开发及运维过程中经常会遇到。Binlog即Binary Log,二进制日志文件,也叫作变更日志(Update Log)。
详细Binglog日志介绍
Binglog主要应用于数据恢复和数据复制,但是在Binlog中也含有非常多有价值的信息,比如说:
- 数据修改事件
- 表结构修改事件
- 状态修改事件
- 事务控制事件
- 管理语句事件
- ......
事务控制事件涵盖了事务的起始时间、起始位置、结束时间和结束位置。通过这些详细信息,我们能够计算事务的大小,进而评估其是否属于大型事务,以及是否可能引起主从同步的延迟问题,及时发现大事务,可避免复制故障。
简介
本文分享的神器的名字就叫做binlog_summary,出自陈臣老师的手笔,也是开源的Python脚本文件,开源地址
下载
运行此工具需要有Python环境,若没有python环境请自行下载
下载binlog_summary.py脚本,并授权- $ wget https://raw.githubusercontent.com/slowtech/dba-toolkit/master/mysql/binlog_summary.py
- $ chmod 755 binlog_summary.py
复制代码 先用./binlog_summary.py -h查看下帮助- $ ./binlog_summary.py -h
- usage: binlog_summary.py [-h] [-f BINLOG_TEXT_FILE] [--new] [-c {tps,opr,transaction}] [--start START_DATETIME] [--stop STOP_DATETIME] [--sort SORT_CONDITION] [-e]
- [--limit LIMIT]
- options:
- -h, --help show this help message and exit
- -f BINLOG_TEXT_FILE, --file BINLOG_TEXT_FILE
- Binlog text file, not the Raw binary file
- --new Make a fresh start
- -c {tps,opr,transaction}, --command {tps,opr,transaction}
- Command type: [tps, opr, transaction],tps: transaction per second, opr: dml per table, transaction: show transaction info
- --start START_DATETIME
- Start datetime, for example: 2004-12-25 11:25:56
- --stop STOP_DATETIME Stop datetime, for example: 2004-12-25 11:25:56
- --sort SORT_CONDITION
- Sort condition: time or size, you can use it when command type is transaction
- -e, --extend Show transaction info in detail,you can use it when command type is transaction
- --limit LIMIT Limit the number of rows to display
复制代码 其中参数介绍:
- -f:Binlog 通过 mysqlbinlog 解析后的文本文件。注意,是文本文件,不是Binlog原始文件。
- --new:工具输出默认存储在sqlite3数据库中。使用--new可删除旧数据库。分析新binlog时需指定。
- -c:指定命令的类型。支持的命令类型有:
- tps:分析实例的TPS信息
- opr:分析表的操作情况
- transaction:分析事务信息
- --start/--stop:指定时间范围
- --sort:事务排序方式,仅针对-c选择为transaction模式
- size,按事务大小排序
- time,按事务的持续时间排序
- -e:输出事务详细操作信息,仅针对-c选择为transaction模式
- limit:限制输出的行数。
最佳实践
前置工作
由于工具只支持解析经mysqlbinlog处理后的文本文件,首先需要进行解析转换。
先从GreatSQL数据目录中复制一份需要分析的binlog文件。- $ cp /data/GreatSQL/binlog.000021 ./
- $ du -h binlog.000021
- 2.0G binlog.000021
复制代码 先使用 mysqlbinlog 解析 Binlog
- 推荐使用参数-v(伪SQL)和--base64-output=decode-rows(不显示Base64编码结果),这样生成的文本文件最小,相应地,binlog_summary工具的解析速度也会更快。
- $ mysqlbinlog --base64-output=decode-rows -v binlog.000021 > ./greatsql-bin.000001.txt
复制代码 解析后的文件大小大概在1.7G左右- $ du -h greatsql-bin.000001.txt
- 1.7G greatsql-bin.000001.txt
复制代码 分析实例的TPS信息
使用-f指定解析后的文件,-c选择分析TPS信息,--limit选择只显示5行- $ ./binlog_summary.py -f ./greatsql-bin.000001.txt -c tps --limit 5
- COMMIT_TIME TPS
- 2024-02-04 14:28:45 1
- 2024-02-04 14:28:56 1
- 2024-02-04 14:28:57 2
- 2024-02-04 14:28:58 1
- 2024-02-04 14:28:59 1
复制代码 这里TPS是根据事务的提交时间进行统计的。获取如此精细TPS信息通常需要通过Binlog来实现,一般的监控手段难以达到如此精细的水平
当然,也可以对TPS进行排序,只需要加上管道和sort。
- k:对第三列排序
- n:是按照数值(默认是字符)的大小进行排序
- r:进行逆序排序
- $ ./binlog_summary.py -f ./greatsql-bin.000001.txt -c tps --limit 5 | sort -k 3 -n
- COMMIT_TIME TPS
- 2024-02-04 14:28:45 1
- 2024-02-04 14:28:56 1
- 2024-02-04 14:28:58 1
- 2024-02-04 14:28:59 1
- 2024-02-04 14:28:57 2
复制代码 分析表的操作情况
如果要分析表操作情况,需要-c选择opr功能模式,NUMS是执行次数,DML_TYPE是执行SQL的类型- $ ./binlog_summary.py -f ./greatsql-bin.000001.txt -c opr --limit 5
- TABLE_NAME DML_TYPE NUMS
- test_db.idx_test INSERT 10000001
- aptest.sys_user INSERT 1002000
- test_db.t1 INSERT 524288
- aptest.sys_dept INSERT 101000
- aptest.sys_user DELETE 1000
复制代码 分析Binlog中的大事务
- $ ./binlog_summary.py -f ./greatsql-bin.000001.txt -c transaction --sort size --limit 5
- TRANS_NAME BEGIN_TIME COMMIT_TIME BEGIN_LOG_POS COMMIT_LOG_POS DURATION_TIME SIZE
- t21 2024-02-05 16:14:32 2024-02-05 16:23:53 14319911 869025248 561 854705337
- t33 2024-02-20 16:02:41 2024-02-20 16:08:21 913362031 1425529317 340 512167286
- t32 2024-02-20 16:01:37 2024-02-20 16:02:06 881773547 913361946 29 31588399
- t31 2024-02-20 16:00:14 2024-02-20 16:00:15 871100835 881773462 1 10672627
- t20 2024-02-04 14:29:43 2024-02-04 14:29:43 7163617 14319264 0 7155647
复制代码 其中,各个参数解析如下
- TRANS_NAME:事务编号
- BEGIN_TIME:事务开始时间
- COMMIT_TIME:事务提交时间
- BEGIN_LOG_POS:事务的开始位置点
- COMMIT_LOG_POS:事务的结束位置点
- DURATION_TIME:事务的持续时间,单位秒。其中,DURATION_TIME = COMMIT_TIME - BEGIN_TIME
- SIZE:事务的大小,单位字节,其中,SIZE = COMMIT_LOG_POS - BEGIN_LOG_POS
拿到事务的大小,可以粗略地判断这个Binlog中是否存在大事务。如果要进一步分析事务中包含哪些操作,需加上–extend,如:- $ ./binlog_summary.py -f ./greatsql-bin.000001.txt -c transaction --sort size --extend --limit 5
- TRANS_NAME BEGIN_TIME COMMIT_TIME BEGIN_LOG_POS COMMIT_LOG_POS DURATION_TIME SIZE
- t21 2024-02-05 16:14:32 2024-02-05 16:23:53 14319911 869025248 561 854705337
- ├── test_db.idx_test INSERT 10000000
- t33 2024-02-20 16:02:41 2024-02-20 16:08:21 913362031 1425529317 340 512167286
- ├── aptest.sys_user INSERT 1000000
- t32 2024-02-20 16:01:37 2024-02-20 16:02:06 881773547 913361946 29 31588399
- ├── aptest.sys_dept INSERT 100000
- t31 2024-02-20 16:00:14 2024-02-20 16:00:15 871100835 881773462 1 10672627
- ├── aptest.tap_dept_tax INSERT 1000
- t20 2024-02-04 14:29:43 2024-02-04 14:29:43 7163617 14319264 0 7155647
- ├── test_db.t1 INSERT 262144
复制代码 性能
实测分析一个2G的Binlog,大概分析时间是2分半,也不慢- $ time python binlog_summary.py -f ./greatsql-bin.000001.txt --new -c transaction --sort size --extend --limit 5
- ......结果不展示
- 154.86s user 2.26s system 99% cpu 2:37.47 total
复制代码 参考阅读
Enjoy GreatSQL
来源:https://www.cnblogs.com/greatsql/p/18093853
免责声明:由于采集信息均来自互联网,如果侵犯了您的权益,请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容,谢谢合作! |
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有账号?立即注册
x
|
|
|
发表于 2024-3-25 11:17:07
举报
回复
分享
|
|
|
|