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

　　跟DBA吵完第三轮，我盯着他工位上那个印着“稳如磐石”的搪瓷杯——底下掉了一小块漆，漏出灰白底色。他刚甩过来的语句还飘在空气里：“你们应用层写死连接不释放，还好意思叫运维设计？”我点头说好，转身就点开Git历史看上周三晚十一点那行注释：// 临时关掉连接池回收，灰度开关没推完。其实没关，只是前端那边改了mock配置，把三个环境都指向了prod库。PM早上十点发群里问“为什么用户头像加载变慢”，测试中午提bug单编号#8873，我下午三点改完提交，七点合并进主干，八点发版。没人点那个开关。它就在那儿，绿着，虚着，跟监控大屏右下角那条蓝色曲线一样——那条是机房空调温控数据，昨儿半夜抖了一下，幅度0.3℃，跟这次崩没半毛钱关系，但我在oncall手机震了一下后第一眼就盯上了它。

　　优胜劣汰？我原以为这词是讲架构选型淘汰掉那些连explain都不看的人。结果去年七月，凌晨两点十八分，线上支付回调接口开始超时，QPS没掉，耗时从一百一十二毫秒直接蹦到三千四百多毫秒，然后断崖式归零。不是数据库挂了，是连不上。Connection refused。DBA查防火墙规则，运维翻SLB日志，我翻自己代码——最后发现是那个被注释掉的HikariCP maxLifetime配置，单位写成了秒，不是毫秒，本地跑三天没问题，上预发三天也撑住了，但一上正式，三十六小时整，所有连接池里的连接同时腐烂。就像一筐桃子，你挑烂的扔掉，可它根本不是逐个烂，是统一过期日到期那一刻集体发霉。这哪是优胜劣汰？这是统一批次报废。我敢打包票，那天所有连接的创建时间戳，误差不超过两秒。

文章配图，仅供参考

　　咖啡杯上印的公司logo少了一道斜杠，左边那撇断了。去年新采购的批次，供应商偷工减料。我端着杯子路过DBA座位时，看见他正用指甲刮自己显示器边框的划痕，一下，两下，第三下停住，抬头问我：“你们APP启动时那个splash页，为啥要查user_device表？”我没接话。因为那张表根本不该在APP启动路径上——是我们上个月为了埋一个“设备首次打开”指标，让后端加了个兜底查询，没走缓存，没设timeout，没做熔断。现在它卡在prepare阶段，等一个锁，而那个锁，正被另一个服务里三百七十二次调用中的第两百零一次卡着。这不是反常识，这是常识塌方现场。

　　后来重跑了一次全量索引重建，DBA手抖多按了一次回车，把online_ddl模式切回inplace，中间卡了四分钟，期间有三十七个订单状态没同步。PM冲进站会室把平板往桌上一拍，屏幕还停留在UAT环境的订单列表页，最新一条时间戳是七月九号二十三点五十九分四十八秒——我们上线前最后一笔模拟交易。他说：“能不能别每次出事都怪SQL？”我说：“能。这次真不怪SQL，怪那个没删干净的测试账号，它还在定时扫优惠券表，每六秒发起一次SELECT COUNT()，而count的字段恰好是刚加的JSON类型。”他顿了两秒，说：“……你截图发我。”我把截图发了，还附了条：倒水的时候洒了半滴在键盘上，Ctrl键现在有点粘。

　　KPI这事挺荒诞的。上季度我的OKR里有一条是“核心链路DB平均响应

（编辑：站长网）

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