mysql 部分故障及解决方案

• 本文主要记录使用 mysql 可能会碰到的一些问题，以及探索相关解决方法

lock wait timeout exceeded

• 环境：问题故障发生在本地局域网主机上安装的 mysql8.0，跑在 docker 中

• 问题描述：本地应用连接时，查询什么的还好，但是修改数据的时候报错，错误信息是lock wait timeout exceeded; try restarting transaction

• 排查：很明显是因为执行更新语句引起的，报错的意思是超过了锁定等待超时时间；尝试重新启动事务

• 解决：参考 https://blog.csdn.net/zc474235918/article/details/72731363 按照文中指示，执行SELECT * FROM information_schema.innodb_trx查询正在运行的事务，。可以看到，这个事务状态是运行状态，并不是锁等待状态，也就是并无异常。正常情况下，如果是被锁的话 kill 掉就行，拿到trx_mysql_thread_id，即事务线程 id，运行kill 2333即可（自行替换线程 id）

• 后续：很明显这里并不是这么简单的问题，状态无问题但是仍然报错。于是我尝试新增一条数据，结果情况一样，插入超时，并且多了一条情况差不多的事务。于是尝试 kill 掉事务线程，结果立马报错Lost connection to MySQL server at 'reading initial communication packet', system error: 0，请看下一节

Lost connection to MySQL server at ‘reading initial communication packet’, system error: 0

• 问题描述：可以理解为由于 kill 掉了一个事务线程，导致需要重新连接，正常情况出现这种问题应该也是某一次发起连接的过程

• 排查：参考： http://aiezu.com/article/mysql_error_at_reading_initial_communication_packet.html 报错信息表达的意思是在读取初始通信包时与 MySQL 服务器的连接断开。可能的原因有很多，但这里是测试环境，负载和连接不多，而且昨天还能用，那可能的原因就是资源不足了。查看了日志，果然是磁盘资源不够，所以只能读取，不能插入和修改

• 解决：参考 https://blog.csdn.net/yjk13703623757/article/details/80283729 清理掉过大的 docker 镜像和日志，腾出空间之后，重启 mysql 服务就好啦

后续

• 解决完问题，让我突然想起了员工辞职的主要两大理由：钱给的不够和干的不爽。是啊，服务好好的突然挂了，罢工了，是不是资源给的不够多，cpu 内存不够用了，亦或是并发量太大网络不好搞得她压力很大让她很不爽

• 所以我们应该时刻关注服务的健康状态，了解她们的需求，不要“又要马儿跑，又要马儿不吃草”