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

　　一年前那场MySQL崩溃，现在想起来手心还发凉。凌晨三点被监控告警震醒，打开站长平台一看，QPS曲线跟跳楼似的往下掉，三百七十二台实例里八十七台主从同步延迟超过五分钟——这数我记得特清楚，因为当时盯着屏幕数了三遍，凉掉的茶在键盘边凝了层水珠，手指敲回车都打滑。

　　我原以为只是普通的连接池耗尽，结果连上服务器才发现更糟：InnoDB缓冲池命中率掉到六十三，慢查询日志里全是全表扫描的SQL，最离谱的是有个开发同学把“order by rand()”写进了核心查询——这哥们后来被我们组集体拉黑，但当时没空收拾他，先得把服务拉起来。

文章配图，仅供参考

　　优胜劣汰这事儿，在MySQL运维里体现得淋漓尽致。我们那套老架构，主从复制用的是传统的binlog+relay log，延迟高的时候能差半小时；后来咬咬牙上了GTID，配合半同步复制，虽然性能掉了点，但至少数据一致性有保障了。最狠的是把慢查询全捞出来，挨个分析执行计划——有个查询走了全表扫描，表里三千万条数据，优化后加了索引，QPS直接涨了四十，这数我敢打包票，因为监控曲线里那根陡坡现在还在我手机相册里存着。

　　但有些坑，躲都躲不过。比如有个开发非说“LIMIT 1000000,10”比“WHERE id > ? LIMIT 10”快，我拿执行计划拍他脸上都不信，结果线上跑了一天，数据库CPU直接飚到九十，主库差点挂掉。后来我们定了死规矩：所有分页查询必须走索引覆盖，否则不许上线——这规矩现在还在用，虽然偶尔有新人抱怨“太麻烦”，但总比半夜爬起来救火强。

　　跟人吵架这事儿，在MySQL运维里太常见了。有次开发说“我们业务特殊，不能用索引”，我直接调出慢查询日志：“你这条SQL走了全表扫描，表大小两G，执行时间三点二秒，你说特殊？那全公司所有业务都特殊！”他没话说了，但第二天偷偷把SQL改了——后来请我喝了杯星巴克，说“哥，还是你狠”。

　　三十六小时里最崩溃的是凌晨六点，主库突然宕机，日志里全是“InnoDB: Assertion failure in thread”。我盯着屏幕看了十分钟，突然想起上个月看过的文档：可能是undo表空间满了。连滚带爬改了innodb_undo_tablespaces参数，重启实例，心跳得跟打鼓似的——结果真成了，服务慢慢恢复，QPS曲线开始往上爬，那一刻差点哭出来。

　　现在回头看，那场崩溃像场噩梦，但也是转机。我们砍掉了所有不必要的索引，把大表拆成小表，上了读写分离，监控告警规则调了又调，现在连周末值班都敢开小差了——当然，只是敢看两眼手机，不敢真走开。

　　对了，站长平台里那张崩溃时的截图，我还存着，偶尔翻出来看看，提醒自己：MySQL运维没有“稳如磐石”，只有“暂时没崩”。下次再遇到这种事，可能不用三十六小时，但肯定还是得熬通宵——不过至少现在，我知道该先改哪个参数，该找谁背锅了。

（编辑：站长网）

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