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

　　隔壁老王剁排骨的刀声震得我秤盘直晃，秤杆上还沾着昨儿挑货时蹭的泥——这破秤该换了，可市场管理处上个月刚涨了摊位费，谁舍得？说回正事儿，去年春晚那档子MySQL崩溃，现在想起来还后怕。那天开档前半小时，系统突然开始抽风，订单表锁死，查询队列堆到八百多，我盯着监控屏上的红字，脑子里第一反应是：完犊子，今晚走货量得腰斩。

　　我原以为只是常规的慢查询，结果一查慢日志，好家伙，有个SQL没加索引，直接全表扫描。那表多大？差不多三千万条记录，春晚当晚的并发量是平时五倍，这哪扛得住？更绝的是，主库的IO利用率已经飙到99%，而从库的复制延迟都到十分钟了——这时候要是主库挂了，从库根本接不住，直接数据不一致，那可比压货赔钱惨多了。

　　收音机里正放着《贵妃醉酒》，我手都抖了，赶紧喊隔壁摊的小李过来帮忙。这小子以前干过运维，现在改行卖海鲜了，但技术还在。我俩蹲在泡沫箱堆里翻配置文件，发现binlog格式居然还是ROW，而主从同步用的是STATEMENT——这组合在高并发下就是定时炸弹，我原以为ROW格式更安全，结果在春晚这种场景下，ROW格式的binlog体积是STATEMENT的三倍，网络带宽直接被撑爆，从库根本追不上主库的进度。

　　地上那摊水一直没干，是昨儿晚上市场水管爆了，现在踩上去还黏糊糊的。小李说：“得改参数，把sync_binlog从1改成100，innodb_flush_log_at_trx_commit从1改成2。”我愣了：“这俩参数改了，数据安全咋办？”他白了我一眼：“现在保命要紧，数据丢了还能从业务日志补，系统崩了今晚走货量归零，你赔得起？”

　　我咬咬牙，照他说的改了。结果刚改完，监控屏上的IO利用率从99%掉到60%，查询队列从八百多降到两百，但新问题又来了：部分订单状态显示不一致，主库显示已支付，从库还是待支付。这时候距离春晚开场还有四十分钟，二批的货车已经在市场门口等着装货了，要是订单状态对不上，这批货得砸手里。

　　小李蹲在秤盘边抽了根烟，说：“得切读写分离，把查询全打到从库，主库只负责写。”我说：“从库延迟十分钟，查询结果能准？”他吐了个烟圈：“准个屁，但总比系统崩了强。你跟二批说，订单状态以主库为准，从库的延迟他们得认——现在行情，能走货就不错了，谁还敢挑？”

　　我硬着头皮给二批打电话，对方在电话里骂了五分钟，但最后还是同意了——毕竟他们也知道，今晚要是拿不到货，明天超市货架就空了，损失更大。改完读写分离，系统总算稳住了，但新问题又来了：从库的复制线程突然挂了，显示“Error 1236: Could not find first log file entry in binlog index”。我盯着错误日志，手心全是汗——这要是修不好，从库彻底废了，主库再挂，数据就全丢了。

　　小李翻出市场管理处的备用服务器，说：“得搭个临时从库，把主库的binlog手动拷贝过来。”我俩蹲在服务器前拷贝文件，市场里的剁肉声、吵架声、收音机的戏声混在一起，像在催命。拷贝到一半，服务器突然断电了——市场管理处说“电路检修”，我差点把键盘砸了。最后用U盘一点点拷，拷完已经晚上八点了，春晚都开始了。

　　临时从库搭起来，复制延迟从十分钟降到两分钟，订单状态总算能对上了。但新问题又来了：部分查询在从库上超时，因为从库的CPU利用率飙到了90%。我原以为是查询太复杂，结果一查，发现是有个SQL用了“ORDER BY RAND()”——这操作在高并发下就是自杀，我直接把那SQL杀了，改用业务逻辑排序，CPU利用率立马掉到30%。

　　那天晚上，系统总算稳住了，但走货量还是比平时少了三成——二批的货车在市场门口堵了两个小时，部分订单超时未支付，自动取消了。我蹲在档口门口抽烟，看着隔壁老王把卖剩下的排骨打包，准备带回家——他今儿也没走完货，损耗比平时高了两成。

　　后来复盘，我发现问题出在“优胜劣汰”——平时系统负载低，很多隐患被掩盖了，比如没加索引的SQL、不合理的binlog格式、致命的“ORDER BY RAND()”。但春晚这种极端场景，把这些隐患全暴露出来了，能扛住的配置和代码活了下来，扛不住的直接崩盘。就像我们档口，平时卖不完的货能压到明天，但春晚这种日子，压货就等于砸手里——市场不会给你第二次机会。

文章配图，仅供参考

　　不过话说回来，这行当就是这样，没有完美的方案，只有权衡和妥协。就像我档口那只晃的灯泡，市场管理处说“下周来换”，但到现在还没换——可生意还得做，系统还得跑，能扛一天是一天吧。

（编辑：航空爱好网）

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