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

　　时间线。去年四月十七号凌晨两点零七分，我蹲在IDC机柜前用手机电筒照MySQL error log，光斑在SSD散热片上晃，手抖得连grep都打错三次。不是怕——是刚灌完半杯冷透的速溶咖啡，心口发麻。总编电话进来那会儿我正拔第三块盘，听见“这选题毙了”五个字，顺手把听筒按在机柜侧面金属壳上，滋啦一声，像硬盘掉进水里。

　　一根蓝色中性笔斜插在小编左耳后，从三点半开会坐到五点四十一分，纹丝没动过。我原以为他记笔记，结果散会时抽出来发现笔帽都没拧开。他手指在键盘上敲“运维实战：36小时…”标题栏，敲到“磐”字卡住，回头问我“这个字读pán还是bān”，我说pán，他点个头继续敲，十秒后删了整行重写。我盯着他右后颈有颗黑痣，比去年夏天大了点，像一块没擦干净的CMOS污点。

文章配图，仅供参考

　　隔壁桌老王的美式洒了，褐色液体顺着U型槽往下流，在地面瓷砖缝里汇成细线，最后停在空调出风口栅格边缘。他没擦，掏出手机拍了一张，发群里叫“新监控图谱：液体延迟”。我没笑。我知道他在嘲哪个值班的——上周那家伙在prometheus里把mysql_up当健康指标，忘了加{job="mysql"}标签过滤，结果把测试环境里一个已停机半年的老MHA节点也判为存活。这事儿现在没人提，但grafana dashboard右下角还挂着“last scraped: 2023-09-14”的幽灵注释。

　　优胜劣汰。这个词不是褒义，是解剖刀。你留着那个不敢改innodb_log_file_size的人，等他哪天把force_recovery=3当成标准恢复流程；你留下那个每次failover都手动stop slave再start，死守5.7时代操作习惯的，三年后他的主从延迟能堆满整个北京西站候车厅；你让谁在配置文件里还写“query_cache_type=1”，就等于把防火墙策略设成any-any。去年四月崩溃后第七个小时，我删了三十七个临时用户，其中八个密码是123456，两个是password，还有一个叫“mysql2024_0417_recovery”——我原以为是脚本生成的，结果查user表发现是某位同事手工CREATE的，时间戳在崩溃前五分钟。

　　外卖袋搁在机房门口铁架上，塑料膜被穿堂风掀起来两次，盒盖翘边了，汤汁渗到纸板层，变成一块深黄色印子。没人去拿。总编发微信说“这篇别写了，改成访谈体”，我回了个“好”，顺手关了手机。其实屏幕底下还在跑pt-heartbeat —r，每两秒打一次心跳，红色光标在终端里跳，像ICU监护仪上那条线。这个我说不准：到底是监控误报率高，还是人对延迟的忍耐阈值真被业务惯坏了？上次我们砍掉一个冗余从库，只因为它的复制延迟持续三天没超1.3秒，可线上有个报表查询还在扫全表。没人管。

　　小编后来问我：“你们网络侧怎么定SLA？”我愣了三秒才答：“我们不说SLA，说MTTR，而且只算‘影响核心业务链路’的。”他说那你这36小时怎么算？我说凌晨两点零七开始，算到第四个从库同步追平，timestamp和master一致，差3毫秒。他皱眉说不够严谨。我没接。他手机突然响了一声，铃声是《命运交响曲》开头四个音符，我差点把手里的KVM切换器砸了。

　　今年工资单刚出，基本工资没涨，绩效系数乘了个0.83。KPI里有一项叫“知识沉淀完成度”，要求每月提交两篇SOP。我上月交了篇《如何安全降级semi-sync为async》，审稿人批注：“场景过于狭窄，建议拓展至跨云多活场景”。我当场在审批意见框里回了句“您先把咱们阿里云RDS主备延迟超60秒的工单闭环再说”，然后点了提交。没撤回。这事跟MySQL无关，但我想说。

　　下次选题会我打算闭嘴。带耳机，捏着那支没动过的蓝色中性笔，假装记笔记。等有人再说“36小时太短，不如写72小时复盘”，我就把笔记本翻过来，背面是上周画的拓扑草图，上面用红笔圈了两处：一处写着“这里没配bonding”，另一处写着“这个防火墙规则谁加的？”。不说话，就指着它。反正他们也不会真去看。

（编辑：站长网）

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