工具分享丨分析GreatSQL Binglog神器
* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。
![]()
在GreatSQL中，Binlog可以说是 GreatSQL 中比较重要的日志了，在日常开发及运维过程中经常会遇到。Binlog即Binary Log，二进制日志文件，也叫作变更日志（Update Log）。
详细Binglog日志介绍：https://greatsql.cn/docs/8032-25/user-manual/2-about-greatsql/4-3-greatsql-binary-log.html
Binglog主要应用于数据恢复和数据复制，但是在Binlog中也含有非常多有价值的信息，比如说：
数据修改事件 表结构修改事件 状态修改事件 事务控制事件 管理语句事件 ......
事务控制事件涵盖了事务的起始时间、起始位置、结束时间和结束位置。通过这些详细信息，我们能够计算事务的大小，进而评估其是否属于大型事务，以及是否可能引起主从同步的延迟问题，及时发现大事务,可避免复制故障。
简介
本文分享的神器的名字就叫做binlog_summary，出自陈臣老师的手笔，也是开源的Python脚本文件，开源地址：https://github.com/slowtech/dba-toolkit/blob/master/mysql/binlog_summary.py
下载
运行此工具需要有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_TIMESIZE：事务的大小，单位字节，其中，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
参考阅读
Binlog分析利器-binlog_summary.py binlog_summary.py源码：https://github.com/slowtech/dba-toolkit/blob/master/mysql/binlog_summary.py
在GreatSQL中，Binlog可以说是 GreatSQL 中比较重要的日志了，在日常开发及运维过程中经常会遇到。Binlog即Binary Log，二进制日志文件，也叫作变更日志（Update Log）。
详细Binglog日志介绍：https://greatsql.cn/docs/8032-25/user-manual/2-about-greatsql/4-3-greatsql-binary-log.html
Binglog主要应用于数据恢复和数据复制，但是在Binlog中也含有非常多有价值的信息，比如说：
数据修改事件 表结构修改事件 状态修改事件 事务控制事件 管理语句事件 ......
事务控制事件涵盖了事务的起始时间、起始位置、结束时间和结束位置。通过这些详细信息，我们能够计算事务的大小，进而评估其是否属于大型事务，以及是否可能引起主从同步的延迟问题，及时发现大事务,可避免复制故障。
简介
本文分享的神器的名字就叫做binlog_summary，出自陈臣老师的手笔，也是开源的Python脚本文件，开源地址：https://github.com/slowtech/dba-toolkit/blob/master/mysql/binlog_summary.py
下载
运行此工具需要有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_TIMESIZE：事务的大小，单位字节，其中，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
参考阅读
Binlog分析利器-binlog_summary.py binlog_summary.py源码：https://github.com/slowtech/dba-toolkit/blob/master/mysql/binlog_summary.py
编译GreatSQL with RocksDB引擎
《GreatSQL运维实战》视频课程
GreatSQL数据库是一款开源免费数据库，可在普通硬件上满足金融级应用场景，具有高可用、高性能、高兼容、高安全等特性，可作为MySQL或Percona Server for MySQL的理想可选替换。
⏩GitHub : https://github.com/GreatSQL/
🆙BiliBili : https://space.bilibili.com/1363850082
（对文章有疑问或见解可去社区官网提出哦~）
| 加入微信交流群 | 加入QQ交流群 |