问题描述
一周前升级过的平台,突然间无法登录了,
初步排查,发现是其中某个服务写数据时,数据库连接超时。
既然是连接超时,
就尝试一下 telnet mysql服务是不是通的,—— 连接没问题。。。
是不是密码错了? —— 密码没有错
重启大法试一下? —— 能启动,但是一旦接收请求时候,就连接超时。
难道是这个服务启动不依赖/不检测MySQL的连接情况? —— 换个服务试一下,貌似也还是能够正常启动
只是这个服务有问题吗? —— 这个服务是登录服务,不登录,好像没太好的办法测试其它业务,虽然可以通过接口调用,但当时确实没用这个方法去验证。并且其它服务启动也没有问题。
用超时的语句去navicat 试一下? —— 竟然真的操作超时了(一个insert 语句)!!! (当时也没有想过,为什么查询语句可以,但写入的数据不行)
是不是锁表了? —— 查了一下,有一大堆的事务未提交。。。emmmm,
把这些事务给 kill 掉? —— kill 事务这个操作也提交不了。
换一张表试试能不能写入? —— 使用 create table xx2 like xx, 然后再insert xx2, 提示“空间不足!!!!!”
终于找到原因了, —— 但是为什么 insert into xx 的时候,它没有这么明显的提示呢?只有用新表的时候,才给了这样的提示???
问题找到
原因就是没有空间了,
既然是没空间 —— 看一下是什么原因导致500G的磁盘被写满了。 df -h 一路查
看到是 mysql 下的 general.log 一个日志文件 300+G, 这可不允许啊,一个日志文件这么大,肯定有古怪。
把这个日志文件看一下,发现它是从近两个月所有mysql的操作语句(查,写)都记录下来了,两个月的操作日志,竟然撑到了300+G。
那这个文件能不能删? (个人感觉是没啥用的,但还是问下 dba 吧)
一番沟通下来后,emmm,使用 “ > general.log” 这个命令可以把数据清掉, 哟西。删吧。
同时使用把这个日志关闭掉 —— SET GLOBAL general_log = off
操作完这两个动作后,直接看疗效: OK了. !!!!
害,竟然捣鼓了这么久。
总结一下:
1、请求超时,不一定是事务有问题或死锁,也可能是空间不够了。
2、定位问题,数据查和写,是否表现出现的现象不一样,比如这里,可查不可写,定位的方向就会缩小很多
3、服务有打印日志,不用纠结那么久,先把语句从日志捞出来,拼好,去执行一下!不用猜,最大可能去还原,这样能省下不少时间
4、尝试使用测试表去验证,有时候会发现“新大陆”,比如在这里,语句拿出来了,虽然发现确实超时,但也不知道为什么,使用另外的测试表,它竟然就提示“没有空间”了,一下子就清晰了起来。
问题原因找到后,就会觉得,这问题真简单,但找到原因前,即使真相就在眼前,也会被忽略掉。
真相离我们很近,就看我们能不能发现它而已。
标签:语句,服务,写入,mysql,日志,超时 From: https://www.cnblogs.com/aaacarrot/p/18396185