MySQL高可用架构：5年实战从单点到自动容灾

　　MySQL高可用架构：5年实战从单点到自动容灾——这标题不是吹的，去年过年期间，杭州机房那场雪崩式断电，主库直接挂了37分钟，哨兵没切、VIP没漂、应用连不上，我盯着Prometheus里那根垂死的连接数曲线，手抖着改DNS指向备库——结果发现备库binlog_position比主库落后14.2万条事务。

　　2019年刚接手系统时，MySQL还在阿里云RDS单节点跑着，连只读副本都舍不得开；2020年Q3上线MHA 0.58，靠Perl脚本+SSH拉起，切主平均耗时2分17秒，但有次因sshd进程僵死导致切换失败——后来查日志发现它居然在/tmp下生成了一个带空格的临时文件名，而shell变量没加引号……这种破事，文档里半个字都没提。

　　去年双十二压测前，我们把集群从Percona XtraDB Cluster（PXC）6.0.22迁到了MySQL InnoDB Cluster 8.0.33，用Group Replication + MySQL Router + AdminAPI自动化管理。实测数据：“MySQL高可用架构：5年实战从单点到自动容灾”——这话我敢写，是因为8月17号凌晨2:43，杭州IDC的sw2交换机BGP路由错乱，三个节点网络分区达89秒，Router自动将流量切到存活节点组，业务无感知，连监控告警都没触发（后来翻日志才发现GR状态在`RECOVERING`态卡了13秒才转`ONLINE`）。

　　但新技术真香吗？我得说句实话：MySQL 8.0.33的group_replication_start_on_boot=OFF这个默认值，差点让我们在一次滚动重启中全军覆没——因为Router缓存了旧拓扑，新节点启动后没主动加入集群，直到第二天早高峰前巡检才发现集群只剩两个节点在线，第三个节点明明活着，却一直被标记为`UNREACHABLE`。这事我问过Oracle Support，他们回复：“这是设计使然”，然后甩了个补丁编号——补丁要等官方正式版才能合入，我们自己打了patch，加了启动后强制调用cluster.forceQuorumUsingPartitionOf()的逻辑，才稳住。

　　中间还踩过一个极冷门的坑：MySQL Router 8.0.33与Linux kernel 5.10.102存在TCP timestamp option兼容性问题，当连接空闲超62秒（恰好是tcp_fin_timeout的默认值），Router会异常关闭后端连接却不通知应用层，Spring Boot的HikariCP池以为连接还活着，直到执行SQL才报“Communications link failure”。我们抓包对比了6台服务器，只有装了特定安全补丁的CentOS 7.9.2009（内核5.10.102-1.el7）复现了该问题——这个组合，在所有公开论坛和BugDB里都没人提过。

文章配图，仅供参考

　　上周我在测试TiDB 7.5的MySQL协议兼容层，发现它能原生支持SELECT ... FOR UPDATE语义一致性，但DDL变更时仍会锁整个region，这点不如MySQL Group Replication的online DDL灵活——不过人家不用管GTID、不用理半同步、也不怕脑裂。所以现在我每天下班前都跑一遍sysbench oltp_read_write + 随机杀节点脚本，就想知道到底哪天能放心把核心账务库切过去。至于当前这套InnoDB Cluster？老实说，我依然会在crontab里保留一条每小时检查group_replication_group_members的命令，加了邮件报警，也加了企业微信机器人推送——因为上个月有次MySQLd进程OOM被kill后，systemd没按预期拉起，它就静静躺在那里，像块没通电的硬盘，谁也不知道。

　　下一步，我想在测试环境接入Vitess的VTTablet做读写分离兜底——虽然它配置复杂得像解九连环，但至少，它能把SELECT语句按shard key自动路由，还不依赖主从延迟阈值判断。

（编辑：站长网）

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