线上服务器down掉4小时全纪录

晚上要上线新功能，大家都很٩(๑>◡<๑)۶呢有木有！

突然这时运维在群里发了一句：服务器出现异常了，怎么肥四？

DBA也开始喊了：mysql咋回事，咋cpu都飙到100%了呢？你们这群开发在干嘛？怎么肥四？

然后后端开发大佬们开始了查问题的过程。

DBA说：没有慢日志，都是小查询把mysql跑满的

观察了一下mysql跑满的记录，似乎是整点就会跑满一次。这时我突然灵光闪现，突然想到下午的时候一个小哥开启了他的定时任务，而他的定时任务就是1小时跑一次，之前没有开过，于是我们想要测试一下到底是不是这个定时任务的问题(注意这时服务器还都正常，只是mysql定时被跑满而已)。

为了证实是这个定时任务的问题，在它第三个整点跑满mysql并且mysql cpu降下来以后，我们人工进行了启动，看定时任务运行中会不会导致mysql跑满，大概过了20分钟，mysql果然被跑满了，这时小哥赶紧关掉了定时任务。

我们以为结束看，然鹅。。。

当我们看日志时才发现，所有应用服务报错的报错，停止运行的停止运行，就算运行正常的访问也会报502.。。

这是肿么了？

我们猜想是数据库的问题，但是DBA查mysql连接数正常，跑的状态也正常。

这时我们想那就重启一下各应用吧，结果都重启不成功，仍然报错，这样的重启持续了将近2小时后，终于我们的小组长

看到了这样的一行日志

Lock

是的，数据库的一些表被锁了，好，终于找到真正的原因了，是时候DBA展示真正的技术了，但是回头一望，我们的DBA

正忙着统计数据，完全顾不上我们，虽然我们这边是线上服务器全面down停，但是(具体原因就不说了，都是工作

的人应该能想到)，于是我们只能靠我们自己有限的力量。我们想到了将mysql的所有连接都杀掉。

首先先看一下mysql目前在执行的sql:show processlist;

看到没有，执行一条update语句需要5000多毫秒，这是要逆天啊，这要是服务能连到mysql才怪了啊，DBA没空理我们，只有运维上了

一刀切，执行：

刚执行完这个语句，我们看到几个应用服务器已经开始正常运行了，于是我们以为正常了，于是我们把其他服务全都启动了。

结果，没过5分钟，又崩溃了。所以这时，要么是mysql连接没有杀完，要么是刚启动的某个应用又导致mysql挂了。这时，

我建议，大家把能关的应用服务都停掉，然后重新杀mysql连接，然后再挨个启动应用服务，启动一个观察2-3分钟，

没问题再启动另一个服务。

好的，计划开始执行，我们小组长先停掉了能停的服务，运维再次执行，刚执行完，这时我们小组长机智的看了

一眼mysql:show processlist,发现并没有杀掉，然后运维这时说了一句，也许需要时间，于是我们等了2分钟，再次查看，

果然杀掉了一部分，而且

update语句执行时间从5000ms到了700毫秒，看来有希望，于是我们继续等待，大概又过了10分钟，

再次查看，是的,sql的执行时间成了1毫秒，

OK基本成功了，于是我们小组长挨个启动应用服务，嗯，全部归位。

这时已经是深夜12点。。。

然后启动定时任务的小哥说了一句：我还是想再启动一下我的任务。。。。

我们全组拒绝！