如何快速找到MYSQLbinlog中的大事物以及生成量分布(infobin工具)
原创注明出处：
1、问题引出：
某些时候需要判断binlog中是否有大事物的存在，比如在解决master-slave延迟
高的情况下。一般我们使用MySQLbinlog来找，但是遇到一个问题，使用mysqbinlog
来找比较麻烦，有没有一个快速的方法呢？当然使用shell脚本来做一些格式化，也
可以找到，这里介绍一个工具叫做infobin 来做，是我自己编写的用C语言完成
2、infobin能做什么？
--找到你大于你指定大小日志量的事物，一般定义为大事物，给出了其位置，通过位置就能在mysqlbinlog的输出
中找到大事物
--找到一个binlog中哪个时间段生成日志量最多
--解析binlog生成event的分布，和部分表语句信息，
--这个binlog文件每秒日志的生成量、最大的event大小，总的事物个数等等
3、如何使用
--USAGE:./infobin [binlogfile] [piece] [bigtrxsize]
[binlogfile]:binlog file!
[piece]:how many piece will split,is a Highly balanced histogram,
find which time generate biggest binlog.(must:piece<2000000)
[bigtrxsize](bytes):larger than this size trx will view.(must:trx>256(bytes))
比如我们要分析72mysql-bin.000586中的大于600K左右的大事物，分10个分片
来判断日志生成量的周期就可以如下：
./infobin 72mysql-bin.000586 10 600000 > log6.log
这里着重解析一下
piece:这是分片参数，比如1G的binlog分为10片那么1片就是100M左右，如果
分片1在100秒内生成，而分片2在10秒内生成，那么可以说明分片2期间
生成的日志量更改，实际上就是100M为大小分为10个桶的大小均衡的直方图
就看哪个片的时间越短就说明这段时间就更忙。
如：
(4)Time:1487561012-1487561480(468(s)) piece:107374204(bytes)[104857.625(kb)]
(5)Time:1487561480-1487562682(1202(s)) piece:107374204(bytes)[104857.625(kb)]
分片5期间生成的日志量就小，分片4期间生成的日志量就大，这里是新纪元时间以来的秒数
可以用LINUX命令换算 如：date -s "@1487035999"
bigtrxsize：这就是这个指定大小binlog生成量将会在最后输出，注意大小是bytes字节，因为row
格式的binlog会记录实际数据，如果是update当然要*2，比如预计数据是每一行是
1000字节，你想输出delete大于1000行的事物，那就是大约1000*1000*4/3=1330000(bytes)
左右，如果是update *2即可.
./infobin 72mysql-bin.000586 10 1330000 >log.log
(10 是piece)
这个是一个变参由自己来定义什么叫做大事物。
4、如何获取工具
获取可以通过百度云盘
http://pan.baidu.com/s/1jHIWUN0
获得，编译的只有LINUX64版本的
限制：
--只能使用在Little_endian上，编译是在LINUX gcc编译的
--load data infile event是没有检测的
--不能读取出row event的语句，因为没有写那么复杂
--可以读取出statement格式的语句，但是为了简洁做了35字节的截断，方便输出
这些东西在mysqlbinlog解析中都有。
--5.6，5.7支持，如果要判断大事物需要使用row格式binlog，否则判断可能有误
5、输出解释：
输出一共分为3段
1、now begin部分：
一目了然需要说明一点Warning:Check This binlog is not closed!说明这个binlog是当前正在使用binlog
2、Detail now部分：
这部分是一个详细的binlog event的输出
--1、
event都以>开始，但是一个事物的event我使用--> ----> ------->来进行区别化更加利于阅读，如果
仔细研究过event这些event一定不会陌生
--2、
Pos:当前event位置
N_pos:下一个event位置，
Gtid: 当然就是GTID如果是匿名事物就是ANONYMOUS 其GTID为0
Time:新纪元时间以来的秒数 可以用LINUX命令换算 如：date -s "@1487035999"
Event_size：这个event有多大
Gno:gtid的事物号部分，我用来标示它们是一个事物
TABLE_ID：是行格式特有的，这个用来保证slave复制的正确性
Use_db: use database 默认当前在哪个数据下，是query event特有的
DB_NAME: 这是map event特有的，也是行格式特有的，记录的是表所在的数据库，和Use_db有区别，
Statment(35b-trun)：在query event中记录的语句为了方便输出将语句做35字节阶段
/*!Trx begin!*/：表示这是一个事物的开始，如果是gtid模式需要向前推一个event，因为gtid event也算到事物中
/*!Trx end*/：自然就是事物的结束点
mysqlbinlog中也是一致的比如：
>Gtid Event:Pos:194(0Xc2) N_pos:259(0X103) Time:1487035999 Event_size:65(bytes)
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1100463
[root@testmy ~]# date -s "@1487035999"
Tue Feb 14 09:33:19 CST 2017
对应mysqlbinlog的如下部分：
# at 194
#170214 9:33:19 server id 93157 end_log_pos 259 CRC32 0xb664a0c6 GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '4a6f2a67-5d87-11e6-a6bd-000c29a879a3:1100463'/*!*/;
3、Total now部分：
这部分是最后的汇总，给出了：
Trx total[counts]: 总的事物个数
Event total[counts]: 总的event个数
Avg binlog size(/sec):平均每秒生成的binlog大小
Avg binlog size(/min):平均每分生成的binlog大小
----Piece view:根据用户指定piece大小得到一个高度均衡直方图，这个直方图用于发现是否有某个时间段生成binlog特别大，
----Large than xxx(bytes) trx:大约xxx BYTES个事，最后会有一个汇总，这部分给出了大事物的开始位置trx_begin_p
结束的位置trx_end_p
列子如下：
-------------Total now--------------
Trx total[counts]:592420
Event total[counts]:3788611
Max trx event size:14344(bytes) Pos:858067571[0X33251273]
Avg binlog size(/sec):261251.109(bytes)[255.128(kb)]
Avg binlog size(/min):15675067.000(bytes)[15307.683(kb)]
--Piece view:
(1)Time:1487560299-1487560543(244(s)) piece:107374204(bytes)[104857.625(kb)]
(2)Time:1487560543-1487560751(208(s)) piece:107374204(bytes)[104857.625(kb)]
(3)Time:1487560751-1487561012(261(s)) piece:107374204(bytes)[104857.625(kb)]
(4)Time:1487561012-1487561480(468(s)) piece:107374204(bytes)[104857.625(kb)]
(5)Time:1487561480-1487562682(1202(s)) piece:107374204(bytes)[104857.625(kb)]
(6)Time:1487562682-1487563492(810(s)) piece:107374204(bytes)[104857.625(kb)]
(7)Time:1487563492-1487563723(231(s)) piece:107374204(bytes)[104857.625(kb)]
(8)Time:1487563723-1487563951(228(s)) piece:107374204(bytes)[104857.625(kb)]
(9)Time:1487563951-1487564159(208(s)) piece:107374204(bytes)[104857.625(kb)]
(10)Time:1487564159-1487564409(250(s)) piece:107374204(bytes)[104857.625(kb)]
--Large than 700000(bytes) trx:
(1)Trx_size:719621(bytes)[702.755(kb)] trx_begin_p:60579814[0X39C5FE6] trx_end_p:61299435[0X3A75AEB]
(2)Trx_size:719771(bytes)[702.901(kb)] trx_begin_p:177760551[0XA986927] trx_end_p:178480322[0XAA364C2]
(3)Trx_size:719779(bytes)[702.909(kb)] trx_begin_p:314334603[0X12BC5D8B] trx_end_p:315054382[0X12C7592E]
(4)Trx_size:719803(bytes)[702.933(kb)] trx_begin_p:317542845[0X12ED51BD] trx_end_p:318262648[0X12F84D78]
(5)Trx_size:719811(bytes)[702.940(kb)] trx_begin_p:367838322[0X15ECC472] trx_end_p:368558133[0X15F7C035]
(6)Trx_size:719765(bytes)[702.896(kb)] trx_begin_p:370735395[0X1618F923] trx_end_p:371455160[0X1623F4B8]
(7)Trx_size:719755(bytes)[702.886(kb)] trx_begin_p:433385835[0X19D4F16B] trx_end_p:434105590[0X19DFECF6]
(8)Trx_size:719827(bytes)[702.956(kb)] trx_begin_p:446989814[0X1AA485F6] trx_end_p:447709641[0X1AAF81C9]
(9)Trx_size:719973(bytes)[703.099(kb)] trx_begin_p:748301414[0X2C9A2C66] trx_end_p:749021387[0X2CA528CB]
(10)Trx_size:719827(bytes)[702.956(kb)] trx_begin_p:915609664[0X36931840] trx_end_p:916329491[0X369E1413]
(11)Trx_size:719765(bytes)[702.896(kb)] trx_begin_p:918974063[0X36C66E6F] trx_end_p:919693828[0X36D16A04]
(12)Trx_size:719797(bytes)[702.927(kb)] trx_begin_p:1029346825[0X3D5A9609] trx_end_p:1030066622[0X3D6591BE]
Total large trx count size(kb):#8435.053(kb)
一目了然，明显Time:1487561480-1487562682(1202(s)) Time:1487562682-1487563492(810(s))
这个时间段生成的日志量较少，其他时间段都比较多。平均大约15307.683(kb)每分钟的日志生成量
如果需要分析第一个大事物是什么只需要在mysqlbinlog的输出中找到位置60579814这个地方看看是什么了。
mysqlbinlog --base64-output='decode-rows' -vv --start-position=60579814 --stop-position=61299435 72mysql-bin.000586 >log.log
即可，注意这里少了一个生成gtid的event的如果要找gtid在前面一个event，这样是不是简单多了？
如果要学习binlog event的知识参考：
http://blog.itpub.net/7728585/viewspace-2133188/ 解析MYSQL BINLOG 二进制格式(1)--准备工作
http://blog.itpub.net/7728585/viewspace-2133189/ 解析MYSQL BINLOG 二进制格式(2)--FORMAT_DESCRIPTION_EVENT
http://blog.itpub.net/7728585/viewspace-2133321/ 解析MYSQL BINLOG 二进制格式(3)--QUERY_EVENT
http://blog.itpub.net/7728585/viewspace-2133429/ 解析MYSQL BINLOG 二进制格式(4)--TABLE_MAP_EVENT
http://blog.itpub.net/7728585/viewspace-2133463/ 解析MYSQL BINLOG 二进制格式(5)--WRITE_ROW_EVENT
http://blog.itpub.net/7728585/viewspace-2133469/ 解析MYSQL BINLOG 二进制格式(6)--UPDATE_ROW_EVENT/DELETE_ROW_EVENT
http://blog.itpub.net/7728585/viewspace-2133502/ 解析MYSQL BINLOG 二进制格式(7)--Xid_log_event/XID_EVENT
http://blog.itpub.net/7728585/viewspace-2133506/ 解析MYSQL BINLOG二进制格式(8)--GTID_LOG_EVENT/ANONYMOUS_GTID_LOG_EVENT及其他
http://blog.itpub.net/7728585/viewspace-2133534/ 解析MYSQL BINLOG二进制格式(9)--infobin解析binlog帮助文档
http://blog.itpub.net/7728585/viewspace-2133537/ 解析MYSQL BINLOG二进制格式(10)--问题解答
本文题目：如何快速找到MYSQLbinlog中的大事物以及生成量分布(infobin工具)
当前URL：http://azwzsj.com/article/ihechd.html
1、问题引出：
某些时候需要判断binlog中是否有大事物的存在，比如在解决master-slave延迟
高的情况下。一般我们使用MySQLbinlog来找，但是遇到一个问题，使用mysqbinlog
来找比较麻烦，有没有一个快速的方法呢？当然使用shell脚本来做一些格式化，也
可以找到，这里介绍一个工具叫做infobin 来做，是我自己编写的用C语言完成
2、infobin能做什么？
--找到你大于你指定大小日志量的事物，一般定义为大事物，给出了其位置，通过位置就能在mysqlbinlog的输出
中找到大事物
--找到一个binlog中哪个时间段生成日志量最多
--解析binlog生成event的分布，和部分表语句信息，
--这个binlog文件每秒日志的生成量、最大的event大小，总的事物个数等等
3、如何使用
--USAGE:./infobin [binlogfile] [piece] [bigtrxsize]
[binlogfile]:binlog file!
[piece]:how many piece will split,is a Highly balanced histogram,
find which time generate biggest binlog.(must:piece<2000000)
[bigtrxsize](bytes):larger than this size trx will view.(must:trx>256(bytes))
比如我们要分析72mysql-bin.000586中的大于600K左右的大事物，分10个分片
来判断日志生成量的周期就可以如下：
./infobin 72mysql-bin.000586 10 600000 > log6.log
这里着重解析一下
piece:这是分片参数，比如1G的binlog分为10片那么1片就是100M左右，如果
分片1在100秒内生成，而分片2在10秒内生成，那么可以说明分片2期间
生成的日志量更改，实际上就是100M为大小分为10个桶的大小均衡的直方图
就看哪个片的时间越短就说明这段时间就更忙。
如：
(4)Time:1487561012-1487561480(468(s)) piece:107374204(bytes)[104857.625(kb)]
(5)Time:1487561480-1487562682(1202(s)) piece:107374204(bytes)[104857.625(kb)]
分片5期间生成的日志量就小，分片4期间生成的日志量就大，这里是新纪元时间以来的秒数
可以用LINUX命令换算 如：date -s "@1487035999"
bigtrxsize：这就是这个指定大小binlog生成量将会在最后输出，注意大小是bytes字节，因为row
格式的binlog会记录实际数据，如果是update当然要*2，比如预计数据是每一行是
1000字节，你想输出delete大于1000行的事物，那就是大约1000*1000*4/3=1330000(bytes)
左右，如果是update *2即可.
./infobin 72mysql-bin.000586 10 1330000 >log.log
(10 是piece)
这个是一个变参由自己来定义什么叫做大事物。
4、如何获取工具
获取可以通过百度云盘
http://pan.baidu.com/s/1jHIWUN0
获得，编译的只有LINUX64版本的
限制：
--只能使用在Little_endian上，编译是在LINUX gcc编译的
--load data infile event是没有检测的
--不能读取出row event的语句，因为没有写那么复杂
--可以读取出statement格式的语句，但是为了简洁做了35字节的截断，方便输出
这些东西在mysqlbinlog解析中都有。
--5.6，5.7支持，如果要判断大事物需要使用row格式binlog，否则判断可能有误
5、输出解释：
输出一共分为3段
1、now begin部分：
一目了然需要说明一点Warning:Check This binlog is not closed!说明这个binlog是当前正在使用binlog
2、Detail now部分：
这部分是一个详细的binlog event的输出
--1、
event都以>开始，但是一个事物的event我使用--> ----> ------->来进行区别化更加利于阅读，如果
仔细研究过event这些event一定不会陌生
--2、
Pos:当前event位置
N_pos:下一个event位置，
Gtid: 当然就是GTID如果是匿名事物就是ANONYMOUS 其GTID为0
Time:新纪元时间以来的秒数 可以用LINUX命令换算 如：date -s "@1487035999"
Event_size：这个event有多大
Gno:gtid的事物号部分，我用来标示它们是一个事物
TABLE_ID：是行格式特有的，这个用来保证slave复制的正确性
Use_db: use database 默认当前在哪个数据下，是query event特有的
DB_NAME: 这是map event特有的，也是行格式特有的，记录的是表所在的数据库，和Use_db有区别，
Statment(35b-trun)：在query event中记录的语句为了方便输出将语句做35字节阶段
/*!Trx begin!*/：表示这是一个事物的开始，如果是gtid模式需要向前推一个event，因为gtid event也算到事物中
/*!Trx end*/：自然就是事物的结束点
mysqlbinlog中也是一致的比如：
>Gtid Event:Pos:194(0Xc2) N_pos:259(0X103) Time:1487035999 Event_size:65(bytes)
Gtid:4a6f2a67-5d87-11e6-a6bd-0c29a879a3:1100463
[root@testmy ~]# date -s "@1487035999"
Tue Feb 14 09:33:19 CST 2017
对应mysqlbinlog的如下部分：
# at 194
#170214 9:33:19 server id 93157 end_log_pos 259 CRC32 0xb664a0c6 GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '4a6f2a67-5d87-11e6-a6bd-000c29a879a3:1100463'/*!*/;
3、Total now部分：
这部分是最后的汇总，给出了：
Trx total[counts]: 总的事物个数
Event total[counts]: 总的event个数
Avg binlog size(/sec):平均每秒生成的binlog大小
Avg binlog size(/min):平均每分生成的binlog大小
----Piece view:根据用户指定piece大小得到一个高度均衡直方图，这个直方图用于发现是否有某个时间段生成binlog特别大，
----Large than xxx(bytes) trx:大约xxx BYTES个事，最后会有一个汇总，这部分给出了大事物的开始位置trx_begin_p
结束的位置trx_end_p
列子如下：
-------------Total now--------------
Trx total[counts]:592420
Event total[counts]:3788611
Max trx event size:14344(bytes) Pos:858067571[0X33251273]
Avg binlog size(/sec):261251.109(bytes)[255.128(kb)]
Avg binlog size(/min):15675067.000(bytes)[15307.683(kb)]
--Piece view:
(1)Time:1487560299-1487560543(244(s)) piece:107374204(bytes)[104857.625(kb)]
(2)Time:1487560543-1487560751(208(s)) piece:107374204(bytes)[104857.625(kb)]
(3)Time:1487560751-1487561012(261(s)) piece:107374204(bytes)[104857.625(kb)]
(4)Time:1487561012-1487561480(468(s)) piece:107374204(bytes)[104857.625(kb)]
(5)Time:1487561480-1487562682(1202(s)) piece:107374204(bytes)[104857.625(kb)]
(6)Time:1487562682-1487563492(810(s)) piece:107374204(bytes)[104857.625(kb)]
(7)Time:1487563492-1487563723(231(s)) piece:107374204(bytes)[104857.625(kb)]
(8)Time:1487563723-1487563951(228(s)) piece:107374204(bytes)[104857.625(kb)]
(9)Time:1487563951-1487564159(208(s)) piece:107374204(bytes)[104857.625(kb)]
(10)Time:1487564159-1487564409(250(s)) piece:107374204(bytes)[104857.625(kb)]
--Large than 700000(bytes) trx:
(1)Trx_size:719621(bytes)[702.755(kb)] trx_begin_p:60579814[0X39C5FE6] trx_end_p:61299435[0X3A75AEB]
(2)Trx_size:719771(bytes)[702.901(kb)] trx_begin_p:177760551[0XA986927] trx_end_p:178480322[0XAA364C2]
(3)Trx_size:719779(bytes)[702.909(kb)] trx_begin_p:314334603[0X12BC5D8B] trx_end_p:315054382[0X12C7592E]
(4)Trx_size:719803(bytes)[702.933(kb)] trx_begin_p:317542845[0X12ED51BD] trx_end_p:318262648[0X12F84D78]
(5)Trx_size:719811(bytes)[702.940(kb)] trx_begin_p:367838322[0X15ECC472] trx_end_p:368558133[0X15F7C035]
(6)Trx_size:719765(bytes)[702.896(kb)] trx_begin_p:370735395[0X1618F923] trx_end_p:371455160[0X1623F4B8]
(7)Trx_size:719755(bytes)[702.886(kb)] trx_begin_p:433385835[0X19D4F16B] trx_end_p:434105590[0X19DFECF6]
(8)Trx_size:719827(bytes)[702.956(kb)] trx_begin_p:446989814[0X1AA485F6] trx_end_p:447709641[0X1AAF81C9]
(9)Trx_size:719973(bytes)[703.099(kb)] trx_begin_p:748301414[0X2C9A2C66] trx_end_p:749021387[0X2CA528CB]
(10)Trx_size:719827(bytes)[702.956(kb)] trx_begin_p:915609664[0X36931840] trx_end_p:916329491[0X369E1413]
(11)Trx_size:719765(bytes)[702.896(kb)] trx_begin_p:918974063[0X36C66E6F] trx_end_p:919693828[0X36D16A04]
(12)Trx_size:719797(bytes)[702.927(kb)] trx_begin_p:1029346825[0X3D5A9609] trx_end_p:1030066622[0X3D6591BE]
Total large trx count size(kb):#8435.053(kb)
一目了然，明显Time:1487561480-1487562682(1202(s)) Time:1487562682-1487563492(810(s))
这个时间段生成的日志量较少，其他时间段都比较多。平均大约15307.683(kb)每分钟的日志生成量
如果需要分析第一个大事物是什么只需要在mysqlbinlog的输出中找到位置60579814这个地方看看是什么了。
mysqlbinlog --base64-output='decode-rows' -vv --start-position=60579814 --stop-position=61299435 72mysql-bin.000586 >log.log
即可，注意这里少了一个生成gtid的event的如果要找gtid在前面一个event，这样是不是简单多了？
如果要学习binlog event的知识参考：
http://blog.itpub.net/7728585/viewspace-2133188/ 解析MYSQL BINLOG 二进制格式(1)--准备工作
http://blog.itpub.net/7728585/viewspace-2133189/ 解析MYSQL BINLOG 二进制格式(2)--FORMAT_DESCRIPTION_EVENT
http://blog.itpub.net/7728585/viewspace-2133321/ 解析MYSQL BINLOG 二进制格式(3)--QUERY_EVENT
http://blog.itpub.net/7728585/viewspace-2133429/ 解析MYSQL BINLOG 二进制格式(4)--TABLE_MAP_EVENT
http://blog.itpub.net/7728585/viewspace-2133463/ 解析MYSQL BINLOG 二进制格式(5)--WRITE_ROW_EVENT
http://blog.itpub.net/7728585/viewspace-2133469/ 解析MYSQL BINLOG 二进制格式(6)--UPDATE_ROW_EVENT/DELETE_ROW_EVENT
http://blog.itpub.net/7728585/viewspace-2133502/ 解析MYSQL BINLOG 二进制格式(7)--Xid_log_event/XID_EVENT
http://blog.itpub.net/7728585/viewspace-2133506/ 解析MYSQL BINLOG二进制格式(8)--GTID_LOG_EVENT/ANONYMOUS_GTID_LOG_EVENT及其他
http://blog.itpub.net/7728585/viewspace-2133534/ 解析MYSQL BINLOG二进制格式(9)--infobin解析binlog帮助文档
http://blog.itpub.net/7728585/viewspace-2133537/ 解析MYSQL BINLOG二进制格式(10)--问题解答
本文题目：如何快速找到MYSQLbinlog中的大事物以及生成量分布(infobin工具)
当前URL：http://azwzsj.com/article/ihechd.html
