昨天测试团队反馈说，跑一些场景用例的时候，发现系统很卡，然后过一段时间就出现无法使用的情况。

于是我这边去排查，先看接口定位到那个服务出现的异常；

然后查看该服务的存于es上的日志，显示Cause: java.sql.SQLException: No operations allowed after statement closed.

出现这种情况，无外乎连接池的连接失效了，但是仍然存在于连接池之中。

检查数据库配置的wait_timeout、连接池大小等信息，发现无异常。

wait_timeout为24小时，连接池大小为1024

于是我这边去修改数据库连接配置，

idle-timeout设置为10分钟connection-timeout设置为30秒connection-test-query原本已存在maximum-pool-size调大为1000

更新验证。

过了一个小时，测试又跑过来说，又不行。

于是在排查观察日志发现还是数据库连接失效。

使用的是mybatis-plus理论上不需要手动关闭连接，连接池泄露风险。

ps:差点就去排查mybatis-plus的源码了。

突然一个念头出现，会不会数据库有问题呢？

于是去K8S看数据库日志。

刚已进入看到数据库被重启了99+次。

于是断定是数据库出现了问题。

去翻看数据库日志，出现InnoDB: corruption in the InnoDB tablespace.

应该是磁盘坏道了，于是回到服务日志，查看是那个sql触发的重启，发现是某个detail表；

于是使用命令对该表进行导出。刚执行导出命令，数据库就重启了。

于是拷贝里面的binlog文件出来，重新在新的节点去部署一个新的数据库。并将有磁盘坏道的设备告知公司的it工程师，由他们去检测以及修改。

题外话：大家对数据库所在设备尽量自己做好阵列，自动监控好设备。避免数据丢失。