MySQL 一个让你怀疑人生的hang死现象

拼搏现实的明天。 2023-06-04 07:56 26阅读 0赞

### 1、故障现象 ###

*  某客户反馈，在利用binlog日志的解析内容做基于时间点的恢复时，出现hang死（超过12小时那种），恢复过程无法继续，而且100%重现
    
     *  基于时间点恢复的实现方式为：使用mysqlbinlog命令指定一个结束时间点，解析binlog并使用管道直接导入数据库中执行（例如：mysqlbinlog binlog\_file | mysql -uroot -pxx）
 *  对此，我们收集了最基本的一些环境信息（注：这是客户环境），如下
    
     *  数据库版本：MySQL 5.7.26
     *  操作系统：CentOS 7.2 x64
     *  服务器配置：  
        \* CPU：8 vcpus  
        \* 磁盘：磁盘阵列  
        \* 内存：16G
     *  数据库关键参数：buffer pool为物理内存的一半，row格式复制
     *  数据库复制拓扑：一主一 从，恢复数据的过程是使用从库的数据全量快照 + 从库的binlog实现，恢复目标服务器是另外一台单独的数据库服务器，该服务器只用于临时恢复数据，不存在复制拓扑，未配置监控或心跳检测
 *  通过简单的询问，确认系统负载不高，数据库也几乎无负载。综合这些信息，在未看到现场之前，我们进行了简单的推理，认为该hang死现象很可能是由于大事务导致的，所以，我们一上去现场就直接围绕数据库进行排查，几经周折，终于发现了问题的原因，而且也找到了解决问题的方法。但，导致hang死的原因远没有想象的那么简单，而且具有一定的迷惑性，我们对此进行一个简单的总结并分享给大家
 *  PS1：下文中的数据为复现数据，复现的服务器配置如下（数据库使用沃趣最佳实践配置模板）
    
     *  CPU：32 vcpus
     *  内存：256G
     *  磁盘：1.6T LSI FLASH卡
     *  网络：万兆网络
 *  PS2：留意下文代码段中的中文注释

### 2、分析排查 ###

*  首先，查看mysqlbinlog进程，可以看到它正在运行着

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 </td> 
 <td> <code>[root@localhost&nbsp;~]#&nbsp;ps&nbsp;aux&nbsp;|grep&nbsp;mysqlbinlog</code> <code>root&nbsp;27822&nbsp;1.3&nbsp;0.0&nbsp;24568&nbsp;3204&nbsp;pts/2&nbsp;R+&nbsp;15:11&nbsp;0:04&nbsp;mysqlbinlog&nbsp;</code><code>--stop-datetime='2019-07-14&nbsp;16:30:00'&nbsp;mysql-bin.000014&nbsp;mysql-bin.000015&nbsp;mysql-bin.000016&nbsp;mysql-bin.000017&nbsp;mysql-bin.000018&nbsp;mysql-bin.000019</code> <code>......</code> </td> 
 </tr> 
 </tbody> 
</table>

*  然后，查看了当前正在运行的线程状态信息，发现一个sleep长达157269S的线程，这是什么鬼。。大事务未提交吗？窃喜！

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 </td> 
 <td> <code>admin@localhost&nbsp;:&nbsp;test&nbsp;02:18:27&gt;&nbsp;show&nbsp;processlist;</code> <code>+</code><code>----+-------+-----------+------+---------+--------+----------+------------------+</code> <code>|&nbsp;Id&nbsp;|&nbsp;</code><code>User</code>&nbsp;<code>|&nbsp;Host&nbsp;|&nbsp;db&nbsp;|&nbsp;Command&nbsp;|&nbsp;</code><code>Time</code>&nbsp;<code>|&nbsp;State&nbsp;|&nbsp;Info&nbsp;|</code> <code>+</code><code>----+-------+-----------+------+---------+--------+----------+------------------+</code> <code>|&nbsp;14&nbsp;|&nbsp;admin&nbsp;|&nbsp;localhost&nbsp;|&nbsp;test&nbsp;|&nbsp;Query&nbsp;|&nbsp;0&nbsp;|&nbsp;starting&nbsp;|&nbsp;show&nbsp;processlist&nbsp;|</code> <code>|&nbsp;15&nbsp;|&nbsp;admin&nbsp;|&nbsp;localhost&nbsp;|&nbsp;test&nbsp;|&nbsp;Sleep&nbsp;|&nbsp;157269&nbsp;|&nbsp;|&nbsp;</code><code>NULL</code>&nbsp;<code>|</code> <code>+</code><code>----+-------+-----------+------+---------+--------+----------+------------------+</code> <code>2&nbsp;</code><code>rows</code>&nbsp;<code>in</code>&nbsp;<code>set</code>&nbsp;<code>(0.00&nbsp;sec)</code> </td> 
 </tr> 
 </tbody> 
</table>

*  接着，我们查看了事务和锁信息

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 </td> 
 <td> <code>#&nbsp;先查看事务信息</code> <code>admin@localhost&nbsp;:&nbsp;test&nbsp;03:02:36&gt;&nbsp;</code><code>select</code>&nbsp;<code>*&nbsp;</code><code>from</code>&nbsp;<code>information_schema.innodb_trx\G</code> <code>Empty&nbsp;</code><code>set</code>&nbsp;<code>(0.00&nbsp;sec)&nbsp;#&nbsp;纳尼！！，居然不存在事务正在运行</code> <code>#&nbsp;然后查看锁信息</code> <code>admin@localhost&nbsp;:&nbsp;test&nbsp;03:30:25&gt;&nbsp;</code><code>select</code>&nbsp;<code>*&nbsp;</code><code>from</code>&nbsp;<code>information_schema.innodb_locks;</code> <code>Empty&nbsp;</code><code>set</code><code>,&nbsp;1&nbsp;warning&nbsp;(0.00&nbsp;sec)&nbsp;#&nbsp;WTF！！居然也没有锁信息</code> </td> 
 </tr> 
 </tbody> 
</table>

*  至此，排查视乎陷入了僵局。既然不存在大事务，也没有锁信息，用于恢复数据的客户端连接也处于Sleep状态，那就表示此时数据库未做任何事情（该数据库是一个用于数据恢复的临时库，并没有任何其他访问业务，也并没有监控、心跳等，只有2个连接，一个是我们登录上去排查问题的连接，另外一个就是使用mysqlbinlog命令恢复数据的客户端连接），那么，为什么会hang？百思不得其解！
 *  再接着，我们查看了一下系统负载，内存、网络、磁盘都几乎无负载，CPU也没啥负载，但却有一个奇怪的现象，有一个CPU核心的利用率为100%，如下

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 </td> 
 <td> <code>top</code>&nbsp;<code>-&nbsp;15:40:50&nbsp;up&nbsp;117&nbsp;days,&nbsp;8:09,&nbsp;5&nbsp;users,&nbsp;</code><code>load</code>&nbsp;<code>average:&nbsp;1.97,&nbsp;1.36,&nbsp;1.15</code> <code>Tasks:&nbsp;496&nbsp;total,&nbsp;2&nbsp;running,&nbsp;494&nbsp;sleeping,&nbsp;0&nbsp;stopped,&nbsp;0&nbsp;zombie</code> <code>%Cpu0&nbsp;:&nbsp;0.0&nbsp;us,&nbsp;0.0&nbsp;sy,&nbsp;0.0&nbsp;ni,100.0&nbsp;id,&nbsp;0.0&nbsp;wa,&nbsp;0.0&nbsp;hi,&nbsp;0.0&nbsp;si,&nbsp;0.0&nbsp;st</code> <code>%Cpu1&nbsp;:&nbsp;0.0&nbsp;us,&nbsp;0.0&nbsp;sy,&nbsp;0.0&nbsp;ni,100.0&nbsp;id,&nbsp;0.0&nbsp;wa,&nbsp;0.0&nbsp;hi,&nbsp;0.0&nbsp;si,&nbsp;0.0&nbsp;st</code> <code>#&nbsp;利用率为100%的CPU核心在这里</code> <code>%Cpu2&nbsp;:&nbsp;34.4&nbsp;us,&nbsp;65.6&nbsp;sy,&nbsp;0.0&nbsp;ni,&nbsp;0.0&nbsp;id,&nbsp;0.0&nbsp;wa,&nbsp;0.0&nbsp;hi,&nbsp;0.0&nbsp;si,&nbsp;0.0&nbsp;st</code> <code>%Cpu3&nbsp;:&nbsp;0.3&nbsp;us,&nbsp;0.3&nbsp;sy,&nbsp;0.0&nbsp;ni,&nbsp;99.3&nbsp;id,&nbsp;0.0&nbsp;wa,&nbsp;0.0&nbsp;hi,&nbsp;0.0&nbsp;si,&nbsp;0.0&nbsp;st</code> <code>%Cpu4&nbsp;:&nbsp;0.0&nbsp;us,&nbsp;0.0&nbsp;sy,&nbsp;0.0&nbsp;ni,100.0&nbsp;id,&nbsp;0.0&nbsp;wa,&nbsp;0.0&nbsp;hi,&nbsp;0.0&nbsp;si,&nbsp;0.0&nbsp;st</code> <code>%Cpu5&nbsp;:&nbsp;0.0&nbsp;us,&nbsp;0.0&nbsp;sy,&nbsp;0.0&nbsp;ni,100.0&nbsp;id,&nbsp;0.0&nbsp;wa,&nbsp;0.0&nbsp;hi,&nbsp;0.0&nbsp;si,&nbsp;0.0&nbsp;st</code> <code>%Cpu6&nbsp;:&nbsp;0.0&nbsp;us,&nbsp;0.0&nbsp;sy,&nbsp;0.0&nbsp;ni,100.0&nbsp;id,&nbsp;0.0&nbsp;wa,&nbsp;0.0&nbsp;hi,&nbsp;0.0&nbsp;si,&nbsp;0.0&nbsp;st</code> <code>%Cpu7&nbsp;:&nbsp;0.0&nbsp;us,&nbsp;0.0&nbsp;sy,&nbsp;0.0&nbsp;ni,100.0&nbsp;id,&nbsp;0.0&nbsp;wa,&nbsp;0.0&nbsp;hi,&nbsp;0.0&nbsp;si,&nbsp;0.0&nbsp;st</code> <code>......</code> </td> 
 </tr> 
 </tbody> 
</table>

*  最后，在恢复库中，我们查看了一下GTID信息，发现GTID号不连续，少了一个事务的GTID（3759）

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 </td> 
 <td> <code>admin@localhost&nbsp;:&nbsp;(none)&nbsp;03:52:08&gt;&nbsp;show&nbsp;master&nbsp;status;</code> <code>+</code><code>------------------+----------+--------------+------------------+---------------------------------------------+</code> <code>|&nbsp;File&nbsp;|&nbsp;Position&nbsp;|&nbsp;Binlog_Do_DB&nbsp;|&nbsp;Binlog_Ignore_DB&nbsp;|&nbsp;Executed_Gtid_Set&nbsp;|</code> <code>+</code><code>------------------+----------+--------------+------------------+---------------------------------------------+</code> <code>|&nbsp;mysql-bin.000013&nbsp;|&nbsp;500&nbsp;|&nbsp;|&nbsp;|&nbsp;5de97c46-a496-11e9-824b-0025905b06da:1-3758,3760-3767&nbsp;|</code> <code>+</code><code>------------------+----------+--------------+------------------+---------------------------------------------+</code> <code>1&nbsp;row&nbsp;</code><code>in</code>&nbsp;<code>set</code>&nbsp;<code>(0.00&nbsp;sec)</code> </td> 
 </tr> 
 </tbody> 
</table>

*  通过查看从库中的GTID（也就是恢复库的数据源对应的库），并没有少GTID号为3759的事务，为什么莫名在恢复库中会少，而不是连续的？带着好奇，我们使用该GTID号解析了从库中的所有被指定用于恢复的binlog file列表（这里指的就是mysql-bin.000014 mysql-bin.000015 mysql-bin.000016 mysql-bin.000017 mysql-bin.000018 mysql-bin.000019），从这些binlog中提取了GTID号为3759的事务的binlog日志内容

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 </td> 
 <td> <code>[root@localhost&nbsp;binlog]#&nbsp;mysqlbinlog&nbsp;mysql-bin.000014&nbsp;mysql-bin.000015&nbsp;mysql-bin.000016&nbsp;mysql-bin.000017&nbsp;mysql-bin.000018&nbsp;mysql-bin.000019&nbsp;</code><code>--include-gtids='5de97c46-a496-11e9-824b-0025905b06da:3759'&nbsp;&gt;&nbsp;b.sql</code> <code>[root@localhost&nbsp;binlog]#&nbsp;ls&nbsp;-lh&nbsp;b.sql</code> <code>-rw-r</code><code>--r--&nbsp;1&nbsp;root&nbsp;root&nbsp;996M&nbsp;Jul&nbsp;14&nbsp;15:59&nbsp;b.sql&nbsp;#&nbsp;My&nbsp;God，GTID号为3759的一个事务binlog日志量快接近一个G了</code> <code>#&nbsp;使用mysqlbinlog命令加-vv选项重新解析（使用-vv选项解析，会导致解析结果的大小翻3倍左右），查看事务的原始语句是怎样的（binlog_rows_query_log_events=</code><code>ON</code><code>才会记录事务的原始语句文本）</code> <code>[root@localhost&nbsp;binlog]#&nbsp;mysqlbinlog&nbsp;-vv&nbsp;mysql-bin.000014&nbsp;mysql-bin.000015&nbsp;mysql-bin.000016&nbsp;mysql-bin.000017&nbsp;mysql-bin.000018&nbsp;mysql-bin.000019&nbsp;</code><code>--include-gtids='5de97c46-a496-11e9-824b-0025905b06da:3759'&nbsp;&gt;&nbsp;c.sql</code> <code>#&nbsp;vim打开c.sql文件查看</code> <code>[root@localhost&nbsp;binlog]#&nbsp;ls&nbsp;-lh</code> <code>total&nbsp;12G</code> <code>-rw-r</code><code>--r--&nbsp;1&nbsp;root&nbsp;root&nbsp;994M&nbsp;Jul&nbsp;14&nbsp;16:38&nbsp;b.sql</code> <code>-rw-r</code><code>--r--&nbsp;1&nbsp;root&nbsp;root&nbsp;2.7G&nbsp;Jul&nbsp;14&nbsp;16:40&nbsp;c.sql</code> <code>......</code> <code>[root@localhost&nbsp;binlog]#&nbsp;vim&nbsp;c.sql</code> <code>......</code> <code>#&nbsp;</code><code>at</code>&nbsp;<code>336</code> <code>#190714&nbsp;16:29:10&nbsp;server&nbsp;id&nbsp;3306102&nbsp;end_log_pos&nbsp;422&nbsp;CRC32&nbsp;0x3b2c9b07&nbsp;Rows_query</code> <code>#&nbsp;发现一个400W行的大事务（经查看sbtest.sbtest1表中的数据量，确认该语句会往test.sbtest1表中插入400W行）</code> <code>#&nbsp;</code><code>insert</code>&nbsp;<code>into</code>&nbsp;<code>sbtest1&nbsp;</code><code>select</code>&nbsp;<code>*&nbsp;</code><code>from</code>&nbsp;<code>sbtest.sbtest1&nbsp;limit&nbsp;4000000</code> <code>......</code> <code>BINLOG&nbsp;'</code> <code>1ucqXRN2cjIAOQAAAN8BAAAAAHUAAAAAAAEABHRlc3QAB3NidGVzdDEABAMD/v4E7mj+tABkzbY1</code> <code>1ucqXR52cjIADSAAAOwhAAAAAHUAAAAAAAAAAgAE//ABAAAAlyomAHcAMzMzNjgzMDQzMTQtMjYx</code> <code>MDIwNDA4ODktMTU4NzIxODA4NzYtMTU0NDIxOTgxNjQtNDYzOTM1NDIxMzEtMTQwODg3NzUzNTQt</code> <code>NzY4MDU0ODgyMTEtNzg0ODM1NTU5NjEtNjMyMDM5NjA0ODEtNDcxNjQ5MDg4MjY7NTA3NzUyOTM0</code> <code>MzctMjE4MzMzNTAzNzYtODc2MTE2NjU0NTYtNjI4NTU3NjAyOTItNDQ3Mjc0MzA4MTjwAwAAAA0z</code> <code>HQB3ADM4NjUyNzU5NDQwLTg4NjY4MjU5MDE3LTk0MDk4ODI4Nzc1LTYxMzMzNjEwMjg0LTYyODc3</code> <code>NDgxMTY3LTY1NzM3Mjg3NTExLTA4MDYwNzA5NTU1LTIzMTUyNjI5NTcxLTE2MDMzMDM2NDE5LTYy</code> <code>MjA0MDgxMzc0OzczOTE3OTQ0NjMzLTc0ODMwMjgwMjE3LTAxMTYzODkwMzkzLTU3NTEzNDA4MDY1</code> <code>LTMwNjgzOTA1MTQ08AUAAAAlNCYAdwAwMjU2MTIyODQ3MC05OTAwMzk1ODMyOC0zMDQ1OTgyMzQw</code> <code>NC0zMTY1MTgyNzE4OC02MDMxODU1MDA5OS03Njk5Njk5MTY3Mi02MTI1Nzg5NTU5MC03NDA3OTQz</code> <code>MDg4MC01NzMyMDA4MzY4NC0zNjAzMDY2NDE4NjszOTA4Nzk4NjM5NC02MjA0NjQ4MDk0Ny01NjQ0</code> <code>NTE4NzA3My0yODQxNDg5MzQyNC03OTYxOTMzMTg1N/AHAAAAn1MmAHcAODgxMzg4MjkxMjEtMDkx</code> <code>NTk1NDI1OTctNzc4ODUwODczMzMtMjA1MzE3NDM2MjktODE3NTQ0NDc2MjgtMjczNDMyMzQ2ODEt</code> <code>......&nbsp;#&nbsp;这就是这个大事务对应的BINLOG编码，整个b.sql文件的994MB的内容主要就是这些BINLOG编码</code> </td> 
 </tr> 
 </tbody> 
</table>

*  分析到这里，总算是发现了导致MySQL 客户端hang死的直接原因（注意，是客户端hang死，不是服务端），即，MySQL客户端在应用一个400W行大事务的binlog时，导致MySQL客户端出现hang死。
 *  但是，问题又来了，一个400W行的大事务，为什么会导致客户端hang死长达12个小时？而且在此期间，数据库和操作系统的负载并不高，数据库的各项参数设定也并没有达到上限，而且，查看了数据库的错误日志和操作系统日志(/var/log/messages)，也并没有发现任何有用信息。
 *  so..，接下来我们就需要进一步分析为何一个大事务会导致客户端hang死

### 3、找到罪魁祸首 ###

*  上文中我们提到过，该故障现象可以100%重现，这为我们进一步分析该问题提供了便利。在开始进一步分析之前，我们先列出在不同磁盘设备的服务器环境中插入400W行大事务的时间参考数据（经验值，不精确）
    
     *  假定内存和CPU不成瓶颈的情况下  
        \* 使用15000转/分的SAS盘时，insert into x select \* from y;语句插入400W行数据大约15分钟内完成  
        \* 使用普通SSD时，insert into x select \* from y;语句插入400W行数据大约5分钟内完成  
        \* 使用FLASH卡时，insert into x select \* from y;语句插入400W行数据大约3分钟内完成
 *  虽然上述提供的参考时间数据不精确，处理一个大事务的BINLOG编码也可能有一些额外的开销，但导入一个400W行大事务的binlog无论如何都不可能超过12个小时
 *  so..，接下来，我们将使用strace、pstack等工具，再结合翻看源码的方式来排查该问题

3.1. strace 工具排查

*  使用strace工具查看登录MySQL并加载binlog解析文本过程中的一些输出信息（这里直接使用上文中提到的b.sql）

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 </td> 
 <td> <code>[root@localhost&nbsp;~]#&nbsp;strace&nbsp;mysql&nbsp;2&gt;&nbsp;strace.txt</code> <code>Welcome&nbsp;</code><code>to</code>&nbsp;<code>the&nbsp;MySQL&nbsp;monitor.&nbsp;Commands&nbsp;</code><code>end</code>&nbsp;<code>with</code>&nbsp;<code>;&nbsp;</code><code>or</code>&nbsp;<code>\g.</code> <code>Your&nbsp;MySQL&nbsp;</code><code>connection</code>&nbsp;<code>id&nbsp;</code><code>is</code>&nbsp;<code>22</code> <code>Server&nbsp;version:&nbsp;5.7.26-log&nbsp;MySQL&nbsp;Community&nbsp;Server&nbsp;(GPL)</code> <code>Copyright&nbsp;(c)&nbsp;2000,&nbsp;2019,&nbsp;Oracle&nbsp;</code><code>and</code><code>/</code><code>or</code>&nbsp;<code>its&nbsp;affiliates.&nbsp;</code><code>All</code>&nbsp;<code>rights&nbsp;reserved.</code> <code>Oracle&nbsp;</code><code>is</code>&nbsp;<code>a&nbsp;registered&nbsp;trademark&nbsp;</code><code>of</code>&nbsp;<code>Oracle&nbsp;Corporation&nbsp;</code><code>and</code><code>/</code><code>or</code>&nbsp;<code>its</code> <code>affiliates.&nbsp;Other&nbsp;names&nbsp;may&nbsp;be&nbsp;trademarks&nbsp;</code><code>of</code>&nbsp;<code>their&nbsp;respective</code> <code>owners.</code> <code>Type&nbsp;</code><code>'help;'</code>&nbsp;<code>or</code>&nbsp;<code>'\h'</code>&nbsp;<code>for</code>&nbsp;<code>help.&nbsp;Type&nbsp;</code><code>'\c'</code>&nbsp;<code>to</code>&nbsp;<code>clear&nbsp;the&nbsp;</code><code>current</code>&nbsp;<code>input&nbsp;statement.</code> <code>admin@localhost&nbsp;:&nbsp;(none)&nbsp;10:49:36&gt;&nbsp;use&nbsp;test</code> <code>Database</code>&nbsp;<code>changed</code> <code>admin@localhost&nbsp;:&nbsp;test&nbsp;10:49:38&gt;&nbsp;source&nbsp;/data/mysqldata1/binlog/b.sql;</code> <code>......</code> <code>Charset&nbsp;changed</code> <code>......</code> <code>Warning&nbsp;(Code&nbsp;1681):&nbsp;Updating&nbsp;</code><code>'collation_database'</code>&nbsp;<code>is</code>&nbsp;<code>deprecated.&nbsp;It&nbsp;will&nbsp;be&nbsp;made&nbsp;</code><code>read</code><code>-</code><code>only</code>&nbsp;<code>in</code>&nbsp;<code>a&nbsp;future&nbsp;release.</code> <code>Query&nbsp;OK,&nbsp;0&nbsp;</code><code>rows</code>&nbsp;<code>affected&nbsp;(0.00&nbsp;sec)</code> <code>#&nbsp;卡在这里了，此时你可以先去干点别的，20分钟之后再回来看看导入成功了没有，不过，不管你等不等，这个客户端要留着后续排查用，不能断开了</code> </td> 
 </tr> 
 </tbody> 
</table>

*  现在，另起一个终端会话，查看strace.txt文件中的内容

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 </td> 
 <td> <code>[root@localhost&nbsp;~]#&nbsp;tailf&nbsp;strace.txt</code> <code>......</code> <code>munmap(0x7f8d6607d000,&nbsp;58281984)&nbsp;=&nbsp;0</code> <code>read</code><code>(4,&nbsp;</code><code>"wMjE4ODQzLTE5MTYzMTE4NDk4LTQwNTA"</code><code>...,&nbsp;4096)&nbsp;=&nbsp;4096</code> <code>mmap(</code><code>NULL</code><code>,&nbsp;58290176,&nbsp;PROT_READ|PROT_WRITE,&nbsp;MAP_PRIVATE|MAP_ANONYMOUS,&nbsp;-1,&nbsp;0)&nbsp;=&nbsp;0x7f8d5f150000</code> <code>......&nbsp;#&nbsp;发现不断地打印类似下面这一段信息，貌似卡在内存分配这里了</code> <code>munmap(0x7f8d628e1000,&nbsp;58298368)&nbsp;=&nbsp;0</code> <code>read</code><code>(4,&nbsp;</code><code>"UxNzUtODUyMjQ1MTkxMDEtMTM4MTk3OD"</code><code>...,&nbsp;4096)&nbsp;=&nbsp;4096</code> <code>mmap(</code><code>NULL</code><code>,&nbsp;58306560,&nbsp;PROT_READ|PROT_WRITE,&nbsp;MAP_PRIVATE|MAP_ANONYMOUS,&nbsp;-1,&nbsp;0)&nbsp;=&nbsp;0x7f8d66077000</code> <code>......</code> </td> 
 </tr> 
 </tbody> 
</table>

*  很无奈，我们使用strace工具在这里并没有发现实质性有用信息，需要使用其他的工具进行排查，现在，你可以关闭用于导数测试的客户端连接了（注意，使用了strace命令之后，客户端连接可以立即终止，如果没有使用strace命令，数据库的终端会话hang死了，无法终止数据库的导数操作，别说我没有等它回滚，我等了好几个小时...）
 *  注意：如果你在跟随我们的复现过程玩耍，建议你查看一下show processlist的信息，你可能会发现之前导入b.sql文件的客户端连接在数据库中并没有被断开，如果发现此情况，则需要在数据库中手工执行kill操作

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 </td> 
 <td> <code>admin@localhost&nbsp;:&nbsp;(none)&nbsp;11:14:54&gt;&nbsp;show&nbsp;processlist;</code> <code>+</code><code>----+-------+-----------+------+---------+-------+----------------------------------+----------------------------------------------------------------------+</code> <code>|&nbsp;Id&nbsp;|&nbsp;</code><code>User</code>&nbsp;<code>|&nbsp;Host&nbsp;|&nbsp;db&nbsp;|&nbsp;Command&nbsp;|&nbsp;</code><code>Time</code>&nbsp;<code>|&nbsp;State&nbsp;|&nbsp;Info&nbsp;|</code> <code>+</code><code>----+-------+-----------+------+---------+-------+----------------------------------+----------------------------------------------------------------------+</code> <code>|&nbsp;22&nbsp;|&nbsp;admin&nbsp;|&nbsp;localhost&nbsp;|&nbsp;test&nbsp;|&nbsp;Sleep&nbsp;|&nbsp;67545&nbsp;|&nbsp;|&nbsp;</code><code>NULL</code>&nbsp;<code>|</code> <code>......</code> <code>|&nbsp;32&nbsp;|&nbsp;admin&nbsp;|&nbsp;localhost&nbsp;|&nbsp;</code><code>NULL</code>&nbsp;<code>|&nbsp;Query&nbsp;|&nbsp;0&nbsp;|&nbsp;starting&nbsp;|&nbsp;show&nbsp;processlist&nbsp;|</code> <code>+</code><code>----+-------+-----------+------+---------+-------+----------------------------------+----------------------------------------------------------------------+</code> <code>admin@localhost&nbsp;:&nbsp;(none)&nbsp;11:14:55&gt;&nbsp;kill&nbsp;22;</code> <code>Query&nbsp;OK,&nbsp;0&nbsp;</code><code>rows</code>&nbsp;<code>affected&nbsp;(0.00&nbsp;sec)</code> </td> 
 </tr> 
 </tbody> 
</table>

3.2. pstack 工具排查

*  登录到MySQL并执行导入b.sql文件操作（不要用strace）

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 </td> 
 <td> <code>[root@localhost&nbsp;~]#&nbsp;mysql&nbsp;-uadmin&nbsp;-ppassword</code> <code>mysql:&nbsp;[Warning]&nbsp;Using&nbsp;a&nbsp;</code><code>password</code>&nbsp;<code>on</code>&nbsp;<code>the&nbsp;command&nbsp;line&nbsp;interface&nbsp;can&nbsp;be&nbsp;insecure.</code> <code>Welcome&nbsp;</code><code>to</code>&nbsp;<code>the&nbsp;MySQL&nbsp;monitor.&nbsp;Commands&nbsp;</code><code>end</code>&nbsp;<code>with</code>&nbsp;<code>;&nbsp;</code><code>or</code>&nbsp;<code>\g.</code> <code>Your&nbsp;MySQL&nbsp;</code><code>connection</code>&nbsp;<code>id&nbsp;</code><code>is</code>&nbsp;<code>31</code> <code>Server&nbsp;version:&nbsp;5.7.26-log&nbsp;MySQL&nbsp;Community&nbsp;Server&nbsp;(GPL)</code> <code>Copyright&nbsp;(c)&nbsp;2000,&nbsp;2019,&nbsp;Oracle&nbsp;</code><code>and</code><code>/</code><code>or</code>&nbsp;<code>its&nbsp;affiliates.&nbsp;</code><code>All</code>&nbsp;<code>rights&nbsp;reserved.</code> <code>Oracle&nbsp;</code><code>is</code>&nbsp;<code>a&nbsp;registered&nbsp;trademark&nbsp;</code><code>of</code>&nbsp;<code>Oracle&nbsp;Corporation&nbsp;</code><code>and</code><code>/</code><code>or</code>&nbsp;<code>its</code> <code>affiliates.&nbsp;Other&nbsp;names&nbsp;may&nbsp;be&nbsp;trademarks&nbsp;</code><code>of</code>&nbsp;<code>their&nbsp;respective</code> <code>owners.</code> <code>Type&nbsp;</code><code>'help;'</code>&nbsp;<code>or</code>&nbsp;<code>'\h'</code>&nbsp;<code>for</code>&nbsp;<code>help.&nbsp;Type&nbsp;</code><code>'\c'</code>&nbsp;<code>to</code>&nbsp;<code>clear&nbsp;the&nbsp;</code><code>current</code>&nbsp;<code>input&nbsp;statement.</code> <code>admin@localhost&nbsp;:&nbsp;(none)&nbsp;11:08:58&gt;&nbsp;use&nbsp;test</code> <code>Database</code>&nbsp;<code>changed</code> <code>admin@localhost&nbsp;:&nbsp;test&nbsp;11:09:00&gt;&nbsp;source&nbsp;/data/mysqldata1/binlog/b.sql;</code> <code>......</code> </td> 
 </tr> 
 </tbody> 
</table>

*  使用pstack工具查看MySQL客户端连接的进程堆栈信息

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 </td> 
 <td> <code>#&nbsp;查看MySQL客户端连接进程号</code> <code>[root@localhost&nbsp;~]#&nbsp;ps&nbsp;aux&nbsp;|grep&nbsp;</code><code>'mysql&nbsp;-uadmin'</code>&nbsp;<code>|grep&nbsp;-v&nbsp;grep</code> <code>root&nbsp;4614&nbsp;81.2&nbsp;0.0&nbsp;175080&nbsp;41284&nbsp;pts/21&nbsp;R+&nbsp;11:18&nbsp;0:20&nbsp;mysql&nbsp;-uadmin&nbsp;-px&nbsp;xxxx</code> <code>#&nbsp;使用pstack工具查看</code> <code>[root@localhost&nbsp;~]#&nbsp;pstack&nbsp;4614&nbsp;|tee&nbsp;-a&nbsp;pstack.txt</code> <code>#&nbsp;发现它卡在__memmove_ssse3_back&nbsp;()内存拷贝的阶段了。此时你可以看到系统的某一个CPU的idle是0%（与上文中发现的CPU负载诡异现象吻合），这个CPU被耗尽的CPU做的事情就是，持续申请内存、拷贝数据、释放内存，自然把一个CPU给用完了</code> <code>#0&nbsp;0x00007f1009f5c315&nbsp;</code><code>in</code>&nbsp;<code>__memmove_ssse3_back&nbsp;()&nbsp;</code><code>from</code>&nbsp;<code>/lib64/libc.so.6</code> <code>#1&nbsp;0x0000000000422adf&nbsp;</code><code>in</code>&nbsp;<code>my_realloc&nbsp;(</code><code>key</code><code>=&lt;optimized&nbsp;</code><code>out</code><code>&gt;,&nbsp;ptr=0x7f0ffde45030,&nbsp;</code><code>size</code><code>=30197464,&nbsp;flags=&lt;optimized&nbsp;</code><code>out</code><code>&gt;)&nbsp;</code><code>at</code>&nbsp;<code>/export/home/pb2/build/sb_0-33648028-1555164244.06/mysql-5.7.26/mysys/my_malloc.c:100</code> <code>#2&nbsp;0x000000000041a2ba&nbsp;</code><code>in</code>&nbsp;<code>String::mem_realloc&nbsp;(this=0xa45460&nbsp;&lt;glob_buffer&gt;,&nbsp;alloc_length=30197460,&nbsp;force_on_heap=&lt;optimized&nbsp;</code><code>out</code><code>&gt;)&nbsp;</code><code>at</code>&nbsp;<code>/export/home/pb2/build/sb_0-33648028-1555164244.06/mysql-5.7.26/sql-common/sql_string.cc:121</code> <code>#3&nbsp;0x0000000000417922&nbsp;</code><code>in</code>&nbsp;<code>add_line&nbsp;(truncated=</code><code>false</code><code>,&nbsp;ml_comment=&lt;optimized&nbsp;</code><code>out</code><code>&gt;,&nbsp;in_string=&lt;optimized&nbsp;</code><code>out</code><code>&gt;,&nbsp;line_length=76,&nbsp;line=0x16b4309&nbsp;</code><code>"NDQ4NDA0LTE5MjQ2NjgzMDgxLTY2MTA0Mjk0ODQ2LTYzNzk3MjcwMjU0LTQ3NjA2Nzk0MTY0LTEx\nODQwNjExOTY5OzY5NTQ1Mjc5MDA2LTM5NTgwMjUzMDEzLTgzMjQxNjU0MzQ1LTA4MDkxMDEzODk1\nLTk5NzMxMDYyMzU58B2TAwABKiYAdwAwNTEzMjEzNDUzNC"</code><code>...,&nbsp;buffer=...)&nbsp;</code><code>at</code>&nbsp;<code>/export/home/pb2/build/sb_0-33648028-1555164244.06/mysql-5.7.26/client/mysql.cc:2795</code> <code>#4&nbsp;read_and_execute&nbsp;(interactive=</code><code>false</code><code>)&nbsp;</code><code>at</code>&nbsp;<code>/export/home/pb2/build/sb_0-33648028-1555164244.06/mysql-5.7.26/client/mysql.cc:2364</code> <code>#5&nbsp;0x00000000004181ef&nbsp;</code><code>in</code>&nbsp;<code>com_source&nbsp;(buffer=&lt;optimized&nbsp;</code><code>out</code><code>&gt;,&nbsp;line=&lt;optimized&nbsp;</code><code>out</code><code>&gt;)&nbsp;</code><code>at</code>&nbsp;<code>/export/home/pb2/build/sb_0-33648028-1555164244.06/mysql-5.7.26/client/mysql.cc:4709</code> <code>#6&nbsp;0x0000000000417099&nbsp;</code><code>in</code>&nbsp;<code>add_line&nbsp;(truncated=</code><code>false</code><code>,&nbsp;ml_comment=&lt;optimized&nbsp;</code><code>out</code><code>&gt;,&nbsp;in_string=&lt;optimized&nbsp;</code><code>out</code><code>&gt;,&nbsp;line_length=37,&nbsp;line=0x16b2a10&nbsp;</code><code>"source&nbsp;/data/mysqldata1/binlog/b.sql;"</code><code>,&nbsp;buffer=...)&nbsp;</code><code>at</code>&nbsp;<code>/export/home/pb2/build/sb_0-33648028-1555164244.06/mysql-5.7.26/client/mysql.cc:2664</code> <code>#7&nbsp;read_and_execute&nbsp;(interactive=</code><code>true</code><code>)&nbsp;</code><code>at</code>&nbsp;<code>/export/home/pb2/build/sb_0-33648028-1555164244.06/mysql-5.7.26/client/mysql.cc:2364</code> <code>#8&nbsp;0x0000000000418c98&nbsp;</code><code>in</code>&nbsp;<code>main&nbsp;(argc=15,&nbsp;argv=0x160c348)&nbsp;</code><code>at</code>&nbsp;<code>/export/home/pb2/build/sb_0-33648028-1555164244.06/mysql-5.7.26/client/mysql.cc:1447</code> </td> 
 </tr> 
 </tbody> 
</table>

*  开心，使用pstack工具发现了一个较为有用的信息，从这里我们知道了MySQL客户端在导入b.sql时，卡在了使用\_\_memmove\_ssse3\_back ()函数做内存拷贝的阶段了
 *  那么问题又来了，为什么会卡在这里？结合上述获取到的信息，我们知道，MySQL客户端只是与服务端建立了一个连接，后续服务端没有收到任何信息（也就是整个客户端hang死期间，服务端没有做任何事情），so..，接下来我们必须要去翻阅源码来寻找答案了：为什么MySQL客户端会卡在 \_\_memmove\_ssse3\_back ()函数内存拷贝阶段？

3.3. 翻阅客户端命令mysql的源码排查

*  由于是在MySQL 5.7.26版本中发生的故障，所以我们首先查看了MySQL 5.7.26版本的客户端源码，MySQL客户端在读取一个文件时（或者说判断什么时候可以将一个操作发送给服务端时），碰到';'分号会直接将前面读取到的内容作为一整个数据包丢给服务端，对上文中提到的b.sql文件中的BINLOG编码，整个BINLOG编码只有一个分号，所以会等到整个BINLOG编码读取完成之后才会发送给服务端，在读取这个超大BINLOG编码的过程中，MySQL客户端会一行一行的读，并记录到global\_buffer中。当global\_buffer申请的空间不足时，就需要扩展内存空间，，扩展内存空间的代码如下：

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 </td> 
 <td> <code>//&nbsp;client/mysql.cc&nbsp;文件</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>if&nbsp;(buffer.length()&nbsp;+&nbsp;length&nbsp;&gt;=&nbsp;buffer.alloced_length())</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>buffer.mem_realloc(buffer.length()+length+IO_SIZE);&nbsp;#&nbsp;每次除了扩展不够的内存以外（原有的内存长度+新读取的内容长度），额外只多扩展了4k的空间（也就是IO_SIZE，IO_SIZE变量的定义大小详见代码段后续的</code><code>"include/my_global.h&nbsp;文件"</code><code>）</code> <code>//&nbsp;mysys/my_malloc.c&nbsp;文件</code> <code>&nbsp;&nbsp;</code><code>new_ptr=&nbsp;my_malloc(</code><code>key</code><code>,&nbsp;</code><code>size</code><code>,&nbsp;flags);&nbsp;#&nbsp;扩展内存时先申请一段新的更大空间的内存（新申请的一段内存的大小为client/mysql.cc&nbsp;文件中描述的扩展之后的内存大小）</code> <code>&nbsp;&nbsp;</code><code>if&nbsp;(likely(new_ptr&nbsp;!=&nbsp;</code><code>NULL</code><code>))</code> <code>&nbsp;&nbsp;</code><code>{ </code> <code>#ifndef&nbsp;DBUG_OFF</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>my_memory_header&nbsp;*new_mh=&nbsp;USER_TO_HEADER(new_ptr);</code> <code>#endif</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>DBUG_ASSERT((new_mh-&gt;m_key&nbsp;==&nbsp;</code><code>key</code><code>)&nbsp;||&nbsp;(new_mh-&gt;m_key&nbsp;==&nbsp;PSI_NOT_INSTRUMENTED));</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>DBUG_ASSERT(new_mh-&gt;m_magic&nbsp;==&nbsp;MAGIC);</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>DBUG_ASSERT(new_mh-&gt;m_size&nbsp;==&nbsp;</code><code>size</code><code>);</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>min_size=&nbsp;(old_size&nbsp;&lt;&nbsp;</code><code>size</code><code>)&nbsp;?&nbsp;old_size&nbsp;:&nbsp;</code><code>size</code><code>;</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>memcpy(new_ptr,&nbsp;ptr,&nbsp;min_size);&nbsp;#&nbsp;然后把数据拷贝过去</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>my_free(ptr);</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>return</code>&nbsp;<code>new_ptr;</code> <code>&nbsp;&nbsp;</code><code>}</code> <code>//&nbsp;include/my_global.h&nbsp;文件</code> <code>#define&nbsp;OS_FILE_LIMIT&nbsp;UINT_MAX</code> <code>/*</code> <code>&nbsp;&nbsp;</code><code>Io&nbsp;buffer&nbsp;</code><code>size</code><code>;&nbsp;Must&nbsp;be&nbsp;a&nbsp;power&nbsp;</code><code>of</code>&nbsp;<code>2&nbsp;</code><code>and</code>&nbsp;<code>a&nbsp;multiple&nbsp;</code><code>of</code>&nbsp;<code>512.&nbsp;May&nbsp;be</code> <code>&nbsp;&nbsp;</code><code>smaller&nbsp;what&nbsp;the&nbsp;disk&nbsp;page&nbsp;</code><code>size</code><code>.&nbsp;This&nbsp;influences&nbsp;the&nbsp;speed&nbsp;</code><code>of</code>&nbsp;<code>the</code> <code>&nbsp;&nbsp;</code><code>isam&nbsp;btree&nbsp;library.&nbsp;eg&nbsp;</code><code>to</code>&nbsp;<code>big&nbsp;</code><code>to</code>&nbsp;<code>slow.</code> <code>*/</code> <code>#define&nbsp;IO_SIZE&nbsp;4096&nbsp;#&nbsp;IO_SIZE&nbsp;变量的大小定义为4K</code> </td> 
 </tr> 
 </tbody> 
</table>

*  通过翻阅源码中的相关代码，再结合b.sql中400W行大事务产生的BINLOG编码，我们可以得出如下结论：
    
     *  MySQL客户端读取b.sql文件中的BINLOG编码时，会把整个BINLOG编码当做一整个数据包对待，也就是说客户端先要将其完整读取并存放在内存中，然后再将其作为一整个数据包发送给服务端（包的大小由客户端和服务端的max\_allowed\_packet参数共同控制，以最小的为准），客户端在读取BINLOG编码的过程中，每读一行都会先判断原先分配的内存是否足够，如果内存不足就需要扩展一下，申请新的一段内存，并且把原来的内存中的数据拷贝过去（新申请的内存），自然就非常慢，看上去就好像客户端hang死一样，而客户端读取BINLOG编码的整个过程中，服务端都没有收到任何的操作，所以，从服务端的show processlist看到线程状态一直是Sleep状态，也没有事务，也没有锁信息。
     *  也就是说，这里可以排除掉mysqlbinlog命令解析binlog的嫌疑

### 4、干掉罪魁祸首 ###

*  虽然，我们发现了问题的根本原因，是因为MySQL客户端读取大事务的BINLOG编码时分配内存的效率太低导致的，但是，怎么解决它呢？改代码？怎么改？改了出其他问题咋办？
 *  IO\_SIZE变量是一个比较底层的变量，不同用途的buffer分配都会使用该变量作为一个基准参考，所以不能直接修改此变量的大小。因此，我们并没有急于去修改客户端代码，而是先尝试使用MySQL 8.0.16、MariaDB 10.1.40/10.2.25/10.3.16/10.4.6、Percona Server 5.7.26进行测试，发现如下现象
    
     *  MySQL 5.7.x和Percona Server 5.7.x：表现一致，客户端hang死
     *  MySQL 8.0.x：在两三分钟之后，客户端连接被服务端断开
     *  MariaDB：表现与MySQL 8.0.x一致
 *  那么，问题又双叒叕来了
    
     *  1）、为什么MariaDB和MySQL 8.0.x会将客户端连接断开，而不像MySQL 5.7.x和Percona Server 5.7.x那样导致MySQL客户端hang死
     *  2）、MySQL 8.0.x在MySQL 5.7.x的基础上做了什么改动使得他们在导入相同数据时的表现不同呢？
 *  我们先解决第一个问题（我想大多数人也是这么想的，对吧），过程很辛酸，最后发现一个很low的问题，就是。。服务端的max\_allowed\_packet系统变量值设置太小了（64M），将其改为1G之后
    
     *  在MariaDB和MySQL 8.0.x中，这个400W行的大事务产生的binlog可以在3分钟以内应用完成（注意，该参数最大值为1G，如果你的事务产生的BINLOG编码长度大于该参数，则仍然会被服务端断开连接）
     *  在MySQL 5.7.x和Percona Server 5.7.x版本中修改该参数为1G之后，也可以应用完成，只是要差不多2天左右的时间，这跟hang死没什么两样，所以问题并没有解决（因为客户使用的是MySQL 5.7.26版本嘛...）
 *  接下来，我们解决第二个问题，比对MySQL 5.7.26和MySQL 8.0.16版本中，关于客户端缓存读取文件数据这块的内存分配代码有什么不同？

<table> 
 <tbody> 
 <tr> 
 <td> 1 2 3 4 5 6 </td> 
 <td> <code>#&nbsp;以下只列出MySQL&nbsp;8.0.16版本中的代码</code> <code>//&nbsp;client/mysql.cc&nbsp;文件</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>if&nbsp;(buffer.length()&nbsp;+&nbsp;length&nbsp;&gt;=&nbsp;buffer.alloced_length())</code> <code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>buffer.mem_realloc(buffer.length()&nbsp;+&nbsp;length&nbsp;+&nbsp;batch_io_size);&nbsp;##&nbsp;8.0中每次扩内存时，额外分配的内存大小变更为了batch_io_size，在5.7中，batch_io_size位置是IO_SIZE</code> <code>//&nbsp;client/my_readline.h&nbsp;文件</code> <code>static</code>&nbsp;<code>const&nbsp;unsigned&nbsp;long&nbsp;</code><code>int</code>&nbsp;<code>batch_io_size&nbsp;=&nbsp;16&nbsp;*&nbsp;1024&nbsp;*&nbsp;1024;&nbsp;##&nbsp;这里定义batch_io_size为16M，从4K变为16M，这就使得客户端在缓存读取的数据时，发现内存不够之后的内存分配效率提高几个数量级</code> </td> 
 </tr> 
 </tbody> 
</table>

*  so...看起来，需要怎么修改MySQL的客户端代码已经很清晰了，只需要新定义一个batch\_io\_size变量，然后将'buffer.mem\_realloc(buffer.length()+length+IO\_SIZE)' 修改为'buffer.mem\_realloc(buffer.length() + length + batch\_io\_size)'即可
 *  说干就干，我们按照此结论对MySQL的客户端mysql的源码进行了修改，重新编译，然后，将服务端和客户端的max\_allowed\_packet参数都设置为1G，重新导入400W行的大事务产生的row格式binlog（即，使用insert into sbtest1 select \* from sbtest.sbtest1 limit 4000000  语句产生的row格式binlog解析文本进行测试），3分钟内完成了导入，至此，问题解决！
 *  最后，多说一句，MariaDB虽然也同样解决了这个问题，但是解决方法完全不同（粗略看了一下代码，没细看），通过比对解析的BINLOG编码，发现MariaDB的BINLOG编码是存在一个个的空缺，所以猜测可能是采用了"mysqlbinlog的解析格式变更"配合"mysql客户端的解析逻辑变更"来解决该问题的（MariaDB在执行导入binlog解析内容时，show processlist查看线程状态也能发现导入数据的线程一直在干活，并不是一直处于Sleep状态），类似如下
    
     *  MariaDB    
        \* BINLOG编码格式
        
        ![format_png][]  
        \* show processlist状态
        
        ![format_png 1][]
     *  MySQL 
        
        \* BINLOG编码格式![format_png 2][]
        
        \* show processlist状态 
        
        ![format_png 3][]

**| 作者简介**

**罗小波·沃趣科技高级数据库技术专家**

IT从业多年，主要负责MySQL 产品的数据库支撑与售后二线支撑。曾参与版本发布系统、轻量级监控系统、运维管理平台、数据库管理平台的设计与编写，熟悉MySQL体系结构，Innodb存储引擎，喜好专研开源技术，多次在公开场合做过线下线上数据库专题分享，发表过多篇数据库相关的研究文章。

[format_png]: /images/20230601/e130d5ce58844109af6c6d711dd45f00.png
[format_png 1]: /images/20230601/bbfeefa94fef4ed8b4bed39c788a3e05.png
[format_png 2]: /images/20230601/c2e0c84d2f3440fd80d15e0782d0c4e8.png
[format_png 3]: /images/20230601/769ce3a26c4d4f369f10833b5af60c55.png