Binlog中，除了具体的SQL，其实，还包含了很多有价值的信息，如，
拿到上面这些信息，我们可以做哪些事情呢？
开发了一个简单的Binlog分析工具-binlog_summary.py，可提取上面这些信息，并在此基础上，进行一些常见分析。
1. 下载地址
2. 参数解析
其中，
- -f：Binlog通过mysqlbinlog解析后的文本文件。注意，是文本文件，不是Binlog原始文件。使用mysqlbinlog解析时，建议指定-v（显示Pseudo SQL，即伪SQL）和–base64-output=decode-rows（不会显示Base64的编码结果）这两个参数，这样，生成的文本文件才是最小的，相应地，binlog_summary.py解析起来也是最快的。具体命令如下：
mysqlbinlog --base64-output=decode-rows -v mysql-bin.000001 > /tmp/mysql-bin.000001.txt
- –new：工具的分析结果默认是存储在sqlite3数据库中。如果指定了–new，会删除之前创建的sqlite3数据库。注意，在对一个新的Binlog进行分析时需指定该参数。
- -c：指定命令的类型。支持的命令类型有：
- tps：分析实例的TPS信息。
- opr：分析表的操作情况。
- transaction：分析事务信息。
- –start：开始时间。分析指定时间段的日志。
- –stop：结束时间。
- –sort：排序条件。当命令类型是transaction时，默认是按照事务的执行顺序输出的，可指定size，按事务大小排序，也可指定time，按事务的持续时间排序。
- -e：当命令类型是transaction时，指定该参数会输出每个事务的详细操作信息。
- –limit：限制输出的行数。
3. 常见用法
注意，这里的TPS是基于事务的提交时间来统计的。
如此细粒度的TPS信息，只能通过Binlog来获取。一般的监控很难做到这一点。
如果要对TPS进行排序，可通过管道 + sort，如，
其中，-k 3是对第三列进行排序，-n是按照数值（默认是字符）的大小进行排序，也可指定-r参数，反向排序。
这里的NUMS是执行次数。
其中，
- 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，如，
4. 实现思路
binlog_summary.py是分析Binlog经过mysqlbinlog解析后的文本文件。具体来说，
接下来，再来说说，为什么是分析Binlog经过mysqlbinlog解析后的文本文件，而不是基于MySQL复制协议，直接分析Binlog呢？基于MySQL复制协议，这种方式有个弊端，就是通用性不够，每出一个新的版本，都要进行相应的适配。
基于文本来分析，很多人可能会觉得不高效。
实际测试了下，分析一个1G的Binlog，大概3min，也不算慢。
Original: https://www.cnblogs.com/ivictor/p/15114460.html
Author: iVictor
Title: Binlog分析利器-binlog_summary.py
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/598970/
转载文章受原作者版权保护。转载请注明原作者出处！