Mysql插入2.6亿条垃圾数据后会发生什么?

问题现象

今天下午业务人员发现某功能无响应(该功能一天前上线)，技术人员初步诊断后发现是某个DB不太正常，DB为Mysql 5.7.18。

登录DB服务器后，进行检测后发现了以下问题：

innodb_trx中发现异常事务

2个事务状态为 inserting ，数据量约为 2.65亿，事务开始时间为昨晚23点

• dw_repayment_monitor空间扩展到73G

事务操做的表占用空间急剧扩大

binlog占满了日志盘

binlog设置的过时时间为10天，文件分片大小为100M。/var/log/mysql下产生了大量的binlog，写满了服务器上的一块日志磁盘

CPU/内存耗尽

top命令后发现CPU全被 mysqld 占用

23G内存所有是buff/cache，内存所有耗尽

解决过程

stop问题应用

首先，紧急stop了问题应用，避免问题升级。

kill 事务对应的mysql thread

kill掉 trx_mysql_thread_id中对应的mysql thread， kill以后，show processlist 已经没法查到这两个thread.

两个事务开始进行rollback

转移binlog

将这些天的binlog转移到其余磁盘，确保mysql binlog可以继续写入

尝试处理两个rollback事务

尝试处理掉两个事务，各类折腾以后，宣告失败。

• 与技术&业务沟通后，知晓该表数据能够自动重建。所以以root用户打算直接删除该表，可是失败

Table is locked by the server

• 发现 innodb_force_recovery,可是不敢乱用
• 发现rollback速度为每秒约1W条，2.6亿数据。回滚须要约7个小时，此时是下午三点多

上报风险

因为本身没有这种状况的处理经验，目前已经没法进一步处理，所以上报至了CTO，避免进一步产生风险。

简要描述状况，CTO初步检测后，给出A/B方案：

• A：先等待正常回滚

• B：若是没法回滚完，考虑中止Mysql. 使用备份数据启用备库

最终结果

因为时间还来得及，采用了A方案，等待DB天然回滚。接下来就是不断检测事务rollback状况，2个rollback事务历经5个小时，到晚上9点终于回滚结束。在此期间，其余同事找到了相应的程序BUG，一个存储过程当中的死循环自昨晚23点开始疯狂往表中插入数据。

因为这张表目前达到73G，所以删除再重建了此表，利用程序进行数据恢复。

总结

平时虽然能处理些Mysql常见问题，但不少极端状况仍是没法处理。一方面是Mysql技能深度不够，另外一方面也是经验的缺失。本文仅记录本次过程，同时也积累了些mysql待学习知识点，其余思考再也不撰写。