MySQL运维实战：36小时从崩溃到高可用

　　我原以为那晚能准时下班。结果七点半监控告警弹出来，主库连接数飙到八百六十七，但show processlist里三百四十二个sleep——全是应用层没设超时的烂活儿。我一边抓鼠标一边啃冷掉的葱油饼，饼渣掉在键盘F键上，按了三下才切进MySQL shell。

　　王磊在机房门口蹲着抽烟，烟头红得跟PROMETHEUS alert面板一样晃眼。他朝我扬下巴：“从崩溃到高可用？你当是修自行车呢。”我没接话，光听见空调外机在隔壁楼顶嘶嘶漏氟，那种持续二十秒的、带颤音的泄压声——后来查了才知道，是上周换的那批新压缩机，出厂批次有问题。

　　优胜劣汰不是口号，是血淋淋的筛选。这三天我亲手删掉十九个自定义备份脚本，其中七个连注释都没写完，剩下一个居然还在用mysqldump --single-transaction加--skip-opt组合——这个我敢打包票，2023年社区补丁早把它标成deprecated了，但没人管。张薇下午三点冲进来递咖啡，杯底还印着“杭州阿里云峰会·2024”，她手指甲掐进纸杯凹痕里，说DBA组要砍人预算。我没接，把咖啡搁在UPS主机散热格栅上，热气立马被吹散成白雾，三秒就没了。

　　故障复盘会开到凌晨一点。运维总监拍桌子说“必须上MHA”，而我盯着投影仪右下角时间戳——23:58:17——突然意识到他根本没看过我们上周写的failover日志分析表。那表就放在共享盘根目录，名字叫《mha_why_we_said_no_v3》，第三行写明了仲裁节点延迟抖动超两百毫秒时，它连切换都卡在wait_for_master_pos()里打转。但他没点开，只盯着PPT里那张画满绿色箭头的架构图。桌上外卖盒掀开了，酸辣粉浮着一层凝固的红油，筷子斜插在里面，像根没拔干净的探针。

　　真正让系统活过来的，是李工半夜改的三行my.cnf。不是innodb_buffer_pool_size，也不是max_connections。是他把table_open_cache_instances从16改成32之后，那个老是卡在opening tables状态的归档JOB，居然在五点十七分自己跑完了。这事我说不准——查过源码，5.7.32以后这个参数对临时表缓存的影响文档里只字未提，但现象就是发生了。窗外开始下雨，不是暴雨，是南方七月特有那种闷着响的毛毛雨，打在玻璃上像指甲轻轻刮。

　　有人问要不要加ProxySQL做读写分离。我摇头。不是技术不行，是那套应用层的脏读逻辑，十年前就埋在Hibernate二级缓存的config.xml第七行。你加再厚的代理层，也盖不住那个用@Transactional(readOnly=true)去调存储过程的老代码。昨天中午刘主任接了个电话，左手捏着手机，右手在便签上划拉：‘客户那边催上线，你们先保读，写停一天’。他划拉完把便签揉成团，扔进旁边绿植盆里——那盆发财树叶子蔫了一半，土表面裂了三道缝。

　　高可用从来不是终点。是我们把所有低效、冗余、自我感动的运维动作，在三十几小时极限压力下筛掉之后，剩下的东西。比如现在监控报警阈值全调低了：连接数超过四百立刻发短信，binlog增长每分钟超二百兆直接语音呼叫，slave_delay大于十八秒自动触发check_replication_status.sh——但这脚本其实只会打印一行‘replication lag detected at $(date)’，然后等着人肉介入。因为自动跳过gtid错误？我们试过两次，一次跳过了主库的DDL锁，一次跳过了从库的temp table残留，结果第二天发现分区表元数据对不上。这个我说不准。

　　我拆过一台下线的备库硬盘。Seagate ST4000NM0035，序列号后面三位是D2T。螺丝刀拧第二颗螺丝时手滑了，崩掉一粒漆，露出底下灰蓝色的金属底色。硬盘里还有三个没清理的test_开头的数据库，其中一个test_backup_202409存着两年前某次迁移失败的原始dump文件。我把这盘塞进工位下面的旧硬盘架，最底下那层，和另外五块同型号的并排。它们现在只是铁块，但谁知道哪天又得通电。

　　前天收拾工位，翻出去年十一月的值班日志本。其中一页写着：‘11月3日 02:14，主库OOM kill mysqld进程。root cause：pt-online-schema-change中途失败后遗留的ghost表锁住innodb dict cache’。下面画了个箭头，旁边补了句‘建议：所有OSC必须绑定timeout+kill signal，否则…’，字没写完，墨水晕开了，像一小片乌云。现在那本子被我垫在显示器支架底下，右边抬高了两毫米，看屏幕不那么累脖子。

文章配图，仅供参考

　　接下来三天，我要重新过一遍所有binlog purge策略。不是为了省磁盘，是上次failover后，发现两个从库的relay-log.info指针差了十六个文件——不是数据丢失，是purge时序错乱导致的position偏移。这事儿没法自动化，得人工比对file名、pos、timestamp三重校验。我打算从周四开始，早上八点来，泡一杯浓茶，等茶凉透喝第一口的时候，开始看第一个relay-log.index。茶凉透需要多久？大概……二百一十三秒吧。我已经测过三次。

（编辑：站长网）

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