今天下午业务人员发现某功能无响应(该功能一天前上线),技术人员初步诊断后发现是某个DB不太正常,DB为Mysql 5.7.18
。
登陆DB服务器后,进行检测后发现了如下问题:
2个事务状态为 inserting ,数据量约为 2.65亿,事务开始时间为昨晚23点
事务操作的表占用空间急剧扩大
binlog设置的过期时间为10天,文件分片大小为100M。/var/log/mysql
下产生了大量的binlog,写满了服务器上的一块日志磁盘
top命令后发现CPU全被 mysqld 占用
23G内存全部是buff/cache,内存全部耗尽
首先,紧急stop了问题应用,避免问题升级。
kill掉 trx_mysql_thread_id中对应的mysql thread, kill之后,show processlist 已经无法查到这两个thread.
两个事务开始进行rollback
将这些天的binlog转移到其他磁盘,确保mysql binlog能够继续写入
尝试处理掉两个事务,各种折腾之后,宣告失败。
Table is locked by the server
由于自己没有这种情况的处理经验,目前已经无法进一步处理,因此上报至了CTO,避免进一步产生风险。
简要描述情况,CTO初步检测后,给出A/B方案:
由于时间还来得及,采用了A方案,等待DB自然回滚。接下来就是不断检测事务rollback情况,2个rollback事务历经5个小时,到晚上9点终于回滚结束。在此期间,其他同事找到了相应的程序BUG,一个存储过程中的死循环自昨晚23点开始疯狂往表中插入数据。
由于这张表目前达到73G,因此删除再重建了此表,利用程序进行数据恢复。
平时虽然能处理些Mysql常见问题,但很多极端情况还是无法处理。一方面是Mysql技能深度不够,另一方面也是经验的缺失。本文仅记录本次过程,同时也积累了些mysql待学习知识点,其他思考不再撰写。
转自网友