36小时MySQL运维实战：从崩溃到高稳

　　去年四月那场MySQL崩溃，我现在想起来还后怕——不是怕数据丢，是怕被产品经理的夺命连环call逼疯。当时是周四晚上十点，监控突然报警，主库CPU直接飚到99%，慢查询堆得跟双十一快递似的。我原以为重启就能搞定，结果刚点下重启键，隔壁测试小妹的外卖到了，她举着奶茶冲监控屏喊“哥你干嘛呢？”，我手一抖，重启卡在半道，整个业务线直接跪了。

　　第一反应是查慢查询日志，结果发现是某个新上线的报表查询，没加索引，全表扫描。我原以为把索引补上就能恢复，结果刚执行完`ALTER TABLE`，主库的IO线程突然卡死——后来才知道是磁盘空间满了，而运维脚本没报错，因为日志文件把剩余空间全占了。这时候产品经理的电话来了，背景音里全是“您拨打的用户正在忙”的机械女声，我盯着屏幕上红得发紫的`SHOW PROCESSLIST`，心想这他妈比写前端兼容性还刺激。

　　凌晨两点，我决定赌一把：把主库降级为从库，从备库提新主库。结果备库的binlog位置没对齐，数据同步差了半小时。我一边敲`CHANGE MASTER TO`一边骂，运维小哥在旁边啃煎饼果子，酱汁滴在键盘上，他擦都不擦，说“哥你快点，我媳妇催我回家”。我抬头看了眼监控屏，发现备库的`Slave_IO_Running`突然变成`No`，心里一沉——这他妈是连锁反应啊。

　　这时候测试小妹凑过来，指着屏幕说：“哥，这个`SELECT FROM users`是不是你写的？”我差点把键盘砸她脸上：“老子写的是前端，这他妈是后端代码！”她哦了一声，转身走了，留下我在机房里对着满屏的`ERROR 1236`发愣。后来才发现，是某个老旧的PHP脚本在循环查全表，而那个脚本的作者，三年前就离职了。

　　凌晨四点，主库终于恢复，但业务线还是报错。查了半天，发现是缓存没更新，导致数据不一致。我让运维小哥清缓存，他说“哥，缓存集群是K8s管的，我得找云平台的人”。我给他一巴掌：“现在找？人家都睡了！”他挠挠头：“那…我试试？”结果他敲`kubectl delete pod`的时候手滑，把整个缓存集群的Pod全删了。我看着监控屏上`Pending`的Pod数量从0变成15，心想这他妈比写Vue组件还容易出错。

　　第二天上午，产品经理召集开会，说“这次事故影响太大了，必须有人背锅”。我原以为他会骂后端，结果他指着我说：“前端也要反思，为什么首屏加载没做好，导致用户频繁刷新，加重了数据库压力？”我差点笑出声——首屏加载慢是因为他非要加十几个第三方统计脚本，其中三个还嵌套了iframe！但我没说话，因为运维小哥在旁边偷偷给我比了个中指，而测试小妹正用口红在白板上画“锅从天降”的漫画。

文章配图，仅供参考

　　现在每次路过机房，我都能听见那台老服务器的风扇在嗡嗡响，像是在说：“下次再这么搞，我就直接宕机。”我摸摸它的外壳，心想：优胜劣汰嘛，你撑住了，我就还能混。而产品经理，大概还在纠结首屏加载能不能压到两秒——虽然他手机是五年前的安卓。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!