MySQL运维设计5大陷阱：14年踩坑血泪总结

　　去年4月份，杭州连续下了一周那种黏糊糊的雨，机房里冷凝水滴在UPS机柜顶上，嗒、嗒、嗒——跟打拍子似的。老张蹲在3号机柜后面接电话，一只手捏着耳塞，另一只手还攥着半截没抽完的烟，烟灰早断了，就剩个红点悬在那儿晃。我盯着监控屏右下角那个MySQL连接数曲线，刚飙到2837，然后“啪”一下断成虚线。

　　不是挂了，是监控探针自己先扛不住了——它用的是Python写的轻量采集脚本，结果连带把慢查询日志解析模块也拖进去了，俩服务共用一个线程池。我原以为撑得住，结果发现它读取slow_log时用了正则匹配全字段，而某开发上周上线了个新报表，SQL里嵌了七层JSON_EXTRACT，日志里光一行就三百七十二个字符。这个我敢打包票，因为我在现场grep了十七遍。

　　陷阱一：把“可观察性”当装饰画贴在墙上。你们信不信？我们曾经给每个库配了独立账号，权限卡得贼死，连SELECT 都报错，可备份脚本用的是root——就因为它要mysqldump --single-transaction，顺手把performance_schema里所有表锁一遍。那天凌晨三点，DBA小陈一边改SQL hint一边嚼口香糖，咔嚓咔嚓，突然说：“哎这行执行计划怎么变橙色了？”没人理他。两分钟后主库READ_ONLY=ON，客服群炸了。这事我没敢声张，但我知道——所谓“权限分离”，最后就是让root穿马甲，戴墨镜，还留了八字胡。

　　那天下雨太大，物业来修屋顶，扛梯子撞翻了1U服务器前的快递箱，里面是运维组订的咖啡。美式漏了一地，顺着静电地板缝往下渗，渗到PDU底下那块，三分钟后2B区供电告警。不是MySQL出问题，是空调冷凝水+咖啡渍+老式PDU外壳老化——仨凑一块，短路跳闸。跳闸本身不致命，命脉是备电切换间隙里，MySQL半开着redo log做崩溃恢复，等它起来，binlog位置对不上了。数据没丢，但中间差了十七秒事务。这个我说不准是不是算幻读，反正业务那边查订单说“钱付了，单没生”，而MySQL说“我啥都没收到”。

文章配图，仅供参考

　　陷阱二：相信“自动切换”比相信你妈还虔诚。我们测过三次MHA failover，平均12.8秒。但去年双11前压力测试，第4次——VIP漂移成功，从库升主库成功，应用连上了，结果第一笔INSERT报Lock wait timeout。为什么？因为那个应用启动脚本里硬编码了--wait_timeout=28800，但它忘了重启前清掉JDBC连接池里的旧链接，那些链接还攥着旧主库的session变量。等真正新连接建起来，库存扣减已经跑偏三次。我那天看日志看到想撕纸，桌上还有半盒没拆封的蓝莓山药——市场部说“给工程师加点健康”，加完当天我就拉肚子两次。

　　其实真不用那么复杂。前天我还看见前端同事老杨（被兼容性折磨了6年前端的老杨）在调试IE11，console里打了个document.querySelector，又删掉，改成$$，再删，最后手写getElementsByTagName。我站在他工位边看了三分钟，一口热茶凉透。他手指头敲空格键的时候，小指翘得老高，跟弹古筝似的。我就想起我们当初给MySQL加audit plugin，就为拦住那个实习生写的delete from user where name like '%test%'——结果插件自己吞了1.2G内存，OOM干掉了mysqld。我们后来把audit关了，换了个更蠢的办法：在my.cnf里加了个init_connect='SET SESSION sql_safe_updates=1'。有用吗？没用。他照样能SET SESSION sql_safe_updates=0。这个事儿我越想越不对劲——你防不住人脑子抽，就跟防不住IE11里Object.assign突然undefined一样。

　　陷阱三：把“标准化”当成万能创可贴。比如慢查询阈值，统一设1s？呵，有个库存服务，高峰期单条SELECT count() FROM order_item WHERE status IN (1,2,3,4,5,6) 用索引扫描也要九百毫秒，他们天天报预警。我们改过五次slow_log阈值，最后一次降到800ms，结果DBA小陈半夜三点微信问我：“老哥，能不能让我调回2s？我快被企业微信消息震聋了。”我盯着屏幕，外卖盒盖没掀开，上面印着“饿了么·闪电送”，时间戳是02:47，订单状态“已送达”——其实早就凉透了，盒底积着浅浅一层油汤。

　　陷阱四：在配置文件里搞微雕艺术。max_connections=512，wait_timeout=28800，innodb_buffer_pool_size=24G——全都精确到个位数。结果上线第二天，发现那个24G是按物理内存96G算的，忘了容器里实际只分配了32G。mysqld吭哧吭哧占满32G后开始疯狂swap，QPS直接跌到个位数。谁干的？是我自己。当时改完conf直接systemctl restart mysqld，没看dmesg，也没碰htop，就点了个刷新。页面白了二十秒，我觉得是网络抖动。这个我真记不清了，可能那会儿窗外雷声太大，也可能我刚挂掉和DBA主管的电话——他说“你先稳住”，我回“稳住啥”，他说“稳住人”，我说“人早跑了”。

　　陷阱五：把“监控告警”当成免责说明书。我们告警里写着“从库延迟>300s”，结果没人去看“复制线程状态”。有个主库DDL执行完没及时commit，从库卡在Waiting for master to send event，延迟一直301s，但复制线程是Running。告警每天准时发，运维当背景噪音听。直到某天产品提需求“加个订单导出”，后台跑了个SELECT … INTO OUTFILE，顺便把master的binlog_format从ROW切成了STATEMENT——没人审，没人拦，没走发布流程。三天后从库崩了一台，因为某个timestamp字段在从库上生成逻辑时间比主库慢十九秒，导致基于时间的WHERE条件失效。我们查了四十分钟，最后发现日志里就一句话：# at 12874619 ——后面跟着一个分号，没有语句。

　　那天收工晚，我看见保洁阿姨推着桶过来拖地，水特别浑，映得天花板灯管歪歪扭扭。她擦到DBA工位时，顺手把小陈桌角那个仙人掌挪了挪位置——那玩意儿晒蔫了，茎都发黄，可根还在土里攥着。我盯着看了十秒，忽然想起一件事：去年4月我们做的那个“高可用架构评审”，会上所有人举手同意用ProxySQL做读写分离，没人问它要不要依赖systemd的restart=always策略。现在想想，说不定那会儿下雨的声音太大，淹掉了关键一句“万一它自己死了呢？”

　　我明天去机房看看那台老PDU，带瓶WD-40。要是能撬开外壳，就喷两下；要是锈死了，我就拍照发群里，写一句：“换吧。”别的不说了。反正咖啡已经凉了，仙人掌也救不回来了。

（编辑：站长网）

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