MySQL高可用运维实战：建站到全栈三合一

　　去年十一月十八号凌晨三点十七分，我蹲在IDC机房第三排冷通道尽头，盯着Zabbix告警屏上跳红的MySQL主从延迟曲线——不是跳红，是整条线被抹平成一条死灰横线，像心电图停了。主库在杭州，从库在无锡，中间跑的是MHA+半同步，理论上切得比眨眼还快。

　　运维老张叼着半截烟站我旁边，突然说：“你信不信，现在连SHOW PROCESSLIST都卡住？”我敲了进去，光标在命令行里闪了二十来秒才吐出第一行结果，第二行直接卡住不动。我原以为是网络抖动，结果发现连接根本没进到mysqld进程里——strace -p 一下，所有新连接全hang在accept() syscall上，队列塞满了， backlog都溢出三回了。

　　我们手忙脚乱切到备用VIP，nginx重试三次后终于把流量导走。可刚松口气，监控显示新主库的binlog dump线程数飙到一百二十六——全是旧主库崩掉前那一分钟里发起的、还没收到ACK的复制请求。这些连接既不超时也不断开，就僵在那儿，占着端口，吃着内存，不读不写不报错。王工在微信里吼：“删连接！删它！”我执行KILL QUERY，返回“Unknown thread id”，再查PROCESSLIST，那一百二十六个线程全消失了，可netstat -ant | grep :3306 还挂着一百二十六个ESTABLISHED。我说不对劲，王工回：“别管，先起新主。”

　　（刚才那台戴尔R730的电源风扇吱啦响了八次，我没理）

　　重启mysqld之前，我照例做了一次xtrabackup备份快照，但tar包打到一半卡住不动——磁盘IO wait飙到98%，iostat一看，/dev/sdb底下有个叫“/var/lib/mysql/.#ib_128_0.dblwr”的临时文件一直在写，大小涨涨停停，停的时间比涨的长。我也不知道它为啥卡在doublewrite buffer刷盘这一步。反正我就等着，等它自己活过来，或者死透。

　　重启后主库起来，服务恢复，Zabbix告警收了。但两小时后，业务侧反馈：用户注册页点提交没反应。排查一圈，发现前端传过来的UUID里有四个字符被截掉——不是前端的问题，是MySQL在重启过程中，某次INSERT INTO users (id, name) 的语句，因server_id变更触发了GTID冲突重试逻辑，结果第二次执行时，字段顺序被优化器临时调整过，触发了一个老版本libmysqlclient的bind参数偏移bug（我们用的PHP 7.4 + mysqli）。这个bug在主库单点运行时不会暴露，只有主从切换后，在从库升主、server_id轮换、GTID_EXECUTED重算这三者叠一起时才咬住。我翻了第八次error log，才在一行带timestamp=2023-11-18T05:41:02的DEBUG级日志里看到“mysql_stmt_execute: param idx 3 out of range”。

　　老张最后把烟头按灭在机柜侧板上，说：“高可用？就是让故障从秒级拖成分钟级，再让修复时间从小时缩成二十分钟——可谁告诉你‘可用’这两个字里不含屎？”

文章配图，仅供参考

　　我原以为只要MHA配置对、半同步开关开了、binlog_format设成ROW，高可用就算落了地；结果发现，一个重启动作能把GTID、客户端驱动、磁盘刷盘策略、甚至PHP扩展的内存布局全串起来，像根湿麻绳，一拽，全绞死。

　　（昨天食堂阿姨多给我舀了半勺梅干菜，咸得我喝了三杯水）

　　现在数据库跑着，表看着也齐，业务说没异常。但凌晨三点十七分那个accept()卡住的瞬间，和五点四十一分那条param idx 3的DEBUG日志，我至今没想通它们之间有没有因果——还是说，就是两个不搭界的故障，在时间上撞了个正着？

　　有谁碰到过这个吗

（编辑：航空爱好网）

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