如何巧妙用Event发现问题
发布时间：2021-12-28 12:35:37 所属栏目：MySql教程 来源：互联网
导读：小编给大家分享一下如何巧用Event发现问题，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！ 有了前面对Event的了解，我们就可以利用这些Event来完成一些工作了。我曾经在学
|
小编给大家分享一下如何巧用Event发现问题，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！ 有了前面对Event的了解，我们就可以利用这些Event来完成一些工作了。我曾经在学习了这些常用的Event后，使用C语言写过一个解析Event的工具，我叫它‘infobin’，意思就是从binary log提取信息的意思。据我所知虽然这个工具在少数情况下会出现BUG但是还是有些朋友在用。我这里并不是要推广我的工具，而是要告诉大家这种思路。我是结合工作中遇到的一些问题来完成了这个工具的，主要功能包含如下： 分析binary log中是否有长期未提交的事务 ，长期不提交的事务将会引发更多的锁争用。 分析binary log中是否有大事务 ，大事务的提交可能会堵塞其它事务的提交。 分析binary log中每个表生成了多少DML Event，这样就能知道哪个表的修改量最大。 分析binary log中Event的生成速度，这样就能知道哪个时间段生成的Event更多。 这个工具的帮助信息如下： [root@gp1 infobin]# ./infobin USAGE ERROR! [Author]: gaopeng [QQ]:22389860 [blog]:http://blog.itpub.net/7728585/ --USAGE:./infobin binlogfile pieces bigtrxsize bigtrxtime [-t] [-force] [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)) [bigtrxtime](sec):larger than this sec trx will view.(must:>0(sec)) [[-t]]:if [-t] no detail is print out,the result will small [[-force]]:force analyze if unkown error check!! 接下来我们具体来看看这几个功能大概是怎么实现的。 一、分析长期未提交的事务 前面我已经多次提到过对于一个手动提交的事务而言有如下特点，我们以‘Insert’语句为列： GTID_LOG_EVENT和XID_EVENT是命令‘COMMIT’发起的时间。 QUERY_EVENT是第一个‘Insert’命令发起的时间。 MAP_EVENT/WRITE_ROWS_EVENT是每个‘Insert’命令发起的时间。 那实际上我们就可以用（1）减去（2）就能得到第一个‘DML’命令发起到‘COMMIT’命令发起之间所消耗的时间，再使用一个用户输入参数来自定义多久没有提交的事务叫做长期未提交的事务就可以了，我的工具中使用bigtrxtime作为这个输入。我们来用一个例子说明，我们做如下语句： 语句 时间 begin T1 insert into testrr values(20); 11:25:22 insert into testrr values(30); 11:25:26 insert into testrr values(40); 11:25:28 commit; 11:25:30 我们来看看Event的顺序和时间如下： |Event|时间| |—-|—-| |GTID_LOG_EVENT|11:25:30| |QUERY_EVENT|11:25:22| |MAP_EVENT（第1个insert）|11:25:22| |WRITE_ROWS_EVENT（第1个insert）|11:25:22| |MAP_EVENT（第2个insert）|11:25:26| |WRITE_ROWS_EVENT（第2个insert）|11:25:26| |MAP_EVENT（第3个insert）|11:25:28| |WRITE_ROWS_EVENT（第3个insert）|11:25:28| |XID_EVENT|11:25:30| 二、分析大事务 这部分实现比较简单，我们只需要扫描每一个事务GTID_LOG_EVENT和XID_EVENT之间的所有Event将它们的总和计算下来，就可以得到每一个事务生成Event的大小（但是为了兼容最好计算QUERY_EVENT和XID_EVENT之间的Event总量）。再使用一个用户输入参数自定义多大的事务叫做大事务就可以了，我的工具中使用bigtrxsize作为这个输入参数。 如果参数binlog_row_image参数设置为‘FULL’，我们可以大概计算一下特定表的每行数据修改生成的日志占用的大小： 三、分析binary log中Event的生成速度 这个实现就很简单了，我们只需要把binary log按照输入参数进行分片，统计结束Event和开始Event的时间差值就能大概算出每个分片生成花费了多久时间，我们工具使用piece作为分片的传入参数。通过这个分析，我们可以大概知道哪一段时间Event生成量更大，也侧面反映了数据库的繁忙程度。 四、分析每个表生成了多少DML Event 这个功能也非常实用，通过这个分析我们可以知道数据库中哪一个表的修改量最大。实现方式主要是通过扫描binary log中的MAP_EVENT和接下来的DML Event，通过table id获取表名，然后将DML Event的大小归入这个表中，做一个链表，最后排序输出就好了。但是前面我们说过table id即便在一个事务中也可能改变，这是我开始没有考虑到的，因此这个工具有一定的问题，但是大部分情况是可以正常运行的。 五、工具展示 下面我就来展示一下我说的这些功能，我做了如下操作： mysql> flush binary logs; Query OK, 0 rows affected (0.51 sec) mysql> select count(*) from tti; +----------+ | count(*) | +----------+ | 98304 | +----------+ 1 row in set (0.06 sec) mysql> delete from tti; Query OK, 98304 rows affected (2.47 sec) mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> insert into tti values(1,'gaopeng'); Query OK, 1 row affected (0.00 sec) mysql> select sleep(20); +-----------+ | sleep(20) | +-----------+ | 0 | +-----------+ 1 row in set (20.03 sec) mysql> commit; Query OK, 0 rows affected (0.22 sec) mysql> insert into tpp values(10); Query OK, 1 row affected (0.14 sec) 在示例中我切换了一个binary log，同时做了3个事务： 删除了tti表数据一共98304行数据。 向tti表插入了一条数据，等待了20多秒提交。 向tpp表插入了一条数据。 我们使用工具来分析一下，下面是统计输出： ./infobin mysql-bin.000005 3 1000000 15 -t > log.log more log.log ... -------------Total now-------------- Trx total[counts]:3 Event total[counts]:125 Max trx event size:8207(bytes) Pos:420[0X1A4] Avg binlog size(/sec):9265.844(bytes)[9.049(kb)] Avg binlog size(/min):555950.625(bytes)[542.921(kb)] --Piece view: (1)Time:1561442359-1561442383(24(s)) piece:296507(bytes)[289.558(kb)] (2)Time:1561442383-1561442383(0(s)) piece:296507(bytes)[289.558(kb)] (3)Time:1561442383-1561442455(72(s)) piece:296507(bytes)[289.558(kb)] --Large than 500000(bytes) trx: (1)Trx_size:888703(bytes)[867.874(kb)] trx_begin_p:299[0X12B] trx_end_p:889002[0XD90AA] Total large trx count size(kb):#867.874(kb) --Large than 15(secs) trx: (1)Trx_sec:31(sec) trx_begin_time:[20190625 14:00:08(CST)] trx_end_time:[20190625 14:00:39(CST)] trx_begin_pos:889067 trx_end_pos:889267 query_exe_time:0 --Every Table binlog size(bytes) and times: Note:size unit is bytes ---(1)Current Table:test.tpp:: Insert:binlog size(40(Bytes)) times(1) Update:binlog size(0(Bytes)) times(0) Delete:binlog size(0(Bytes)) times(0) Total:binlog size(40(Bytes)) times(1) ---(2)Current Table:test.tti:: Insert:binlog size(48(Bytes)) times(1) Update:binlog size(0(Bytes)) times(0) Delete:binlog size(888551(Bytes)) times(109) Total:binlog size(888599(Bytes)) times(110) ---Total binlog dml event size:888639(Bytes) times(111) 我们发现我们做的操作都统计出来了： 当然也可以通过mysqlbinlog 进行解析后，然后通过shell/python去统计，但是这个工具的速度要远远快于这种方式。 以上是“如何巧用Event发现问题”这篇文章的所有内容，感谢各位的阅读！ （编辑：锡盟站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐