工具分享丨分析 GreatSQL Binglog 神器

作者：GreatSQL

2024-03-25
福建
本文字数：3807 字
阅读完需：约 12 分钟

工具分享丨分析 GreatSQL Binglog 神器

在 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 -husage: 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 5COMMIT_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 5TABLE_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 5TRANS_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 5TRANS_NAME      BEGIN_TIME           COMMIT_TIME          BEGIN_LOG_POS   COMMIT_LOG_POS  DURATION_TIME   SIZEt21             2024-02-05 16:14:32  2024-02-05 16:23:53  14319911        869025248       561             854705337├──             test_db.idx_test                          INSERT          10000000t33             2024-02-20 16:02:41  2024-02-20 16:08:21  913362031       1425529317      340             512167286├──             aptest.sys_user                           INSERT          1000000t32             2024-02-20 16:01:37  2024-02-20 16:02:06  881773547       913361946       29              31588399├──             aptest.sys_dept                           INSERT          100000t31             2024-02-20 16:00:14  2024-02-20 16:00:15  871100835       881773462       1               10672627├──             aptest.tap_dept_tax                       INSERT          1000t20             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

发布于: 刚刚阅读数: 5

原文链接:【http://xie.infoq.cn/article/0d289956dcae72c29a2f3563e】。文章转载请联系作者。

GreatSQL

关注

GreatSQL社区 2023-01-31 加入

GreatSQL是由万里数据库维护的MySQL分支，专注于提升MGR可靠性及性能，支持InnoDB并行查询特性，是适用于金融级应用的MySQL分支版本。社区：https://greatsql.cn/ Gitee: https://gitee.com/GreatSQL/GreatSQL

发布

暂无评论

创作场景

工具分享丨分析 GreatSQL Binglog 神器

工具分享丨分析 GreatSQL Binglog 神器

简介

下载

最佳实践

前置工作

分析实例的 TPS 信息

分析表的操作情况

分析 Binlog 中的大事务

性能

参考阅读

GreatSQL

评论