MySQL运维实战：36小时从崩溃到稳如磐石

　　去年一月份那破事儿，现在想起来还手心冒汗——凌晨三点，监控群突然炸了，三十多个报警短信叠着发，手机屏幕亮得跟探照灯似的。我原以为只是普通的慢查询，结果连上服务器一看，主库CPU直接飚到99%，InnoDB缓冲池命中率掉到60%，慢查询日志里全是全表扫描的SQL，最离谱的是有个UPDATE语句没加索引，扫了八百多万行数据——这他妈是生产库啊，谁写的代码？

　　当时运维组的小王正蹲在机房角落啃煎饼果子，油渍蹭在服务器机柜上，我冲他喊“主库崩了”，他手一抖，煎饼掉进机柜缝隙里。我一边骂“你他妈能不能别在机房吃东西”，一边抓起键盘开始查进程——结果发现除了那个作死的UPDATE，还有三个定时任务同时在跑全量统计，其中一个统计脚本里居然嵌了三层子查询，执行计划里全是“Using filesort”。这时候窗外开始下雨，雨点砸在机房的玻璃上，噼里啪啦的，跟报警声混在一起，听得人脑仁疼。

　　我原以为直接kill掉那几个作死进程就能缓过来，结果kill完不到两分钟，CPU又飚回99%——原来有个从库的IO线程卡死了，主库的binlog积压了三个G，复制延迟直接跳到“不可用”。这时候开发总监的电话打进来，背景音里能听见他闺女在哭，他扯着嗓子喊“用户反馈订单页打不开了，你们运维在干嘛？”，我回他“在救火，别催”，挂了电话看了眼时间，凌晨四点十七分。

　　接下来三十六小时，基本是“发现问题-解决问题-发现新问题”的循环。比如我们原以为调整缓冲池大小能缓解压力，结果发现服务器内存只有64G，缓冲池设到40G后，系统OOM杀了MySQL进程；又比如我们想通过读写分离分散压力，结果从库的硬件配置比主库还烂，查询一多直接宕机；最绝的是有个开发说“我们加个缓存吧”，结果缓存键设计得稀烂，导致缓存穿透，数据库压力反而更大了——这时候我特别想冲进开发办公室，把他们的键盘都砸了。

文章配图，仅供参考

　　中间有个插曲：早上九点，测试组的小李举着手机冲进运维办公室，说“用户反馈登录页也慢了”，我瞄了眼监控，发现登录接口的SQL执行时间从50ms涨到300ms——结果一查，是测试环境的数据量只有生产的十分之一，开发在测试环境写的SQL能跑通，到生产就跪了。我把小李按在椅子上，指着屏幕说“看见没？这就是为什么我们强调生产环境测试”——他挠挠头，说“我以为你们运维只管服务器”。

　　到第二天下午五点，主库终于稳了。我瘫在椅子上，看着监控群里“一切正常”的提示，突然想起昨天凌晨小王掉进机柜的煎饼果子——那煎饼现在应该已经发霉了吧？这时候开发总监又发消息，说“用户反馈现在流畅多了，谢谢啊”，我回了个“哦”，然后把手机倒扣在桌上——妈的，这三十六小时的罪，谁爱受谁受。

　　现在回头看，这事儿能成，真不是靠什么高深技术，就是“把该砍的砍了，把该优化的优化了”。那些“能用就行”的SQL，那些“暂时不影响”的定时任务，那些“先凑合着”的硬件配置——平时不觉得是问题，一到崩溃的时候，全成了压垮骆驼的稻草。所以我现在跟新人说，运维的核心不是“救火”，是“防火”——把那些该淘汰的淘汰掉，把该优化的优化掉，剩下的，才能稳如磐石。

　　不过话说回来，那三十六小时里，我最怕的不是主库崩了，是开发说“我们改个配置就能解决”——这种话，十次有九次是坑。下次再遇到这种事，我可能得先收走他们的root权限，省得他们乱动。

（编辑：站长网）

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