# 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](https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html),但是不敢乱用 * 发现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待学习知识点，其他思考不再撰写。