#8203;MySQL 一个使你怀疑人生的hang死现象
发布时间：2022-03-31 23:27:02 所属栏目：MySql教程 来源：互联网
导读：MySQL 一个让你怀疑人生的hang死现象： 1、故障现象 某客户反馈，在利用binlog日志的解析内容做基于时间点的恢复时，出现hang死（超过12小时那种），恢复过程无法继续，而且100%重现 基于时间点恢复的实现方式为：使用mysqlbinlog命令指定一个结束时间点，
|
MySQL 一个让你怀疑人生的hang死现象： 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进程，可以看到它正在运行着 [root@localhost ~]# ps aux |grep mysqlbinlog root 27822 1.3 0.0 24568 3204 pts/2 R+ 15:11 0:04 mysqlbinlog --stop-datetime='2019-07-14 16:30:00' mysql-bin.000014 mysql-bin.000015 mysql-bin.000016 mysql-bin.000017 mysql-bin.000018 mysql-bin.000019 ...... 然后，查看了当前正在运行的线程状态信息，发现一个sleep长达157269S的线程，这是什么鬼。。大事务未提交吗？窃喜！ admin@localhost : test 02:18:27> show processlist; +----+-------+-----------+------+---------+--------+----------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-------+-----------+------+---------+--------+----------+------------------+ | 14 | admin | localhost | test | Query | 0 | starting | show processlist | | 15 | admin | localhost | test | Sleep | 157269 | | NULL | +----+-------+-----------+------+---------+--------+----------+------------------+ 2 rows in set (0.00 sec) 接着，我们查看了事务和锁信息 # 先查看事务信息 admin@localhost : test 03:02:36> select * from information_schema.innodb_trxG Empty set (0.00 sec) # 纳尼！！，居然不存在事务正在运行 # 然后查看锁信息 admin@localhost : test 03:30:25> select * from information_schema.innodb_locks; 最后，在恢复库中，我们查看了一下GTID信息，发现GTID号不连续，少了一个事务的GTID（3759） admin@localhost : (none) 03:52:08> show master status; +------------------+----------+--------------+------------------+---------------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+---------------------------------------------+ | mysql-bin.000013 | 500 | | | 5de97c46-a496-11e9-824b-0025905b06da:1-3758,3760-3767 | +------------------+----------+--------------+------------------+---------------------------------------------+ 1 row in set (0.00 sec) [root@localhost binlog]# vim c.sql ...... # at 336 #190714 16:29:10 server id 3306102 end_log_pos 422 CRC32 0x3b2c9b07 Rows_query # 发现一个400W行的大事务（经查看sbtest.sbtest1表中的数据量，确认该语句会往test.sbtest1表中插入400W行） # insert into sbtest1 select * from sbtest.sbtest1 limit 4000000 NTE4NzA3My0yODQxNDg5MzQyNC03OTYxOTMzMTg1N/AHAAAAn1MmAHcAODgxMzg4MjkxMjEtMDkx NTk1NDI1OTctNzc4ODUwODczMzMtMjA1MzE3NDM2MjktODE3NTQ0NDc2MjgtMjczNDMyMzQ2ODEt ...... # 这就是这个大事务对应的BINLOG编码，整个b.sql文件的994MB的内容主要就是这些BINLOG编码 分析到这里，总算是发现了导致MySQL 客户端hang死的直接原因（注意，是客户端hang死，不是服务端），即，MySQL客户端在应用一个400W行大事务的binlog时，导致MySQL客户端出现hang死。 但是，问题又来了，一个400W行的大事务，为什么会导致客户端hang死长达12个小时？而且在此期间，数据库和操作系统的负载并不高，数据库的各项参数设定也并没有达到上限，而且，查看了数据库的错误日志和操作系统日志(/var/log/messages)，也并没有发现任何有用信息。 （编辑：PHP编程网 - 黄冈站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330482号