MySQL高可用架构：6年域名运维实战容灾方案

发布时间：2026-10-12 08:20:32 所属栏目：MySql教程来源：DaWei

导读：　　MySQL高可用架构：6年域名运维实战容灾方案——这标题不是我拍脑袋想的，是我去年10月在处理“.xyz”批量注册接口雪崩时，盯着PMM监控里主库QPS断崖式跌到37后，用红笔写在机房白板上的原话。那会儿VIP切换花了4.8秒，中间

　　MySQL高可用架构：6年域名运维实战容灾方案——这标题不是我拍脑袋想的，是我去年10月在处理“.xyz”批量注册接口雪崩时，盯着PMM监控里主库QPS断崖式跌到37后，用红笔写在机房白板上的原话。那会儿VIP切换花了4.8秒，中间丢了112条WHOIS变更记录，客户凌晨三点打电话过来骂“你们的域名还能不能查”，我把耳机线拔了，泡了杯速溶咖啡重读MHA文档。

　　我们真实跑过三套方案：Percona XtraDB Cluster（2021年上线，共7节点，部署在阿里云华北2和华南1双可用区），MySQL Group Replication（2022年灰度，但遇到DNS解析超时导致member_status反复变FLUID——后来发现是VPC内/etc/resolv.conf里的search域多写了两个冗余项，删掉后才稳定）；还有被我们自己推翻的MaxScale读写分离+keepalived，去年10月那次故障就栽在这上面：keepalived脑裂时VIP同时出现在两台服务器上，备库把主库binlog当成relay log回放，直接把域名锁定表锁成了死循环——那晚我手动kill了23个mysqld进程，其中5个带--skip-grant-tables启动，因为权限表也被误刷坏了。

文章配图，仅供参考

　　真正扛住压力的是今年新上的Orchestrator+raft选举+ProxySQL的组合，节点心跳间隔设为800ms，仲裁用3个etcd实例（192.168.11.103/104/105），但有个坑别人很少提：当ProxySQL后端权重设为100-100-0时，哪怕第3台标为0，Orchestrator也会把它当候选节点发probe请求，结果它响应慢半拍就被踢出集群——我们测试发现，必须明确加/+ max_replication_lag=10 /这样的hint，不然某个从库延迟飙升到12.7秒时，ProxySQL照旧转发SELECT过去，导致域名whois查询返回陈旧的过期状态。

　　新技术。

　　这套架构不是完美无缺。上周五（2024年6月21日）下午4:17，我们测试主动触发etcd leader迁移，结果ProxySQL连接池爆满，173个未释放的mysql连接占用内存1.2GB，OOM Killer干掉了syslogd——最后靠重启rsyslog.service硬拉回来，日志断了8分钟。这事我没报事故等级，只在内部钉钉群打了个表情包????，毕竟没影响客户查whois或支付，但说明orchestrator底层对连接风暴的阻断逻辑仍有模糊地带。要不要切回Consul？暂时不敢动。另外，我们所有binlog都保留7天（参数expire_logs_days=7），但实际磁盘只留5.3天，因为purge命令执行时机被crond错峰在凌晨2:15，而每天0:03有一次全量备份，两者IO争抢导致两次purge失败，日志堆积在/mysql/binlog/下多出了12GB未清理文件——这事监控告警静默了整整3天，直到运维同事手动df -h扫目录才撞见。所以现在我每天早9点盯一眼inodes使用率，超过92%就人工介入。技术再新，也得有人盯着磁盘。

　　MySQL高可用架构：6年域名运维实战容灾方案。

　　准备下周拿阿里云PolarDB-X做AB对比压测，用真实的.cn域名注册流（峰值TPS 4860）跑三天。如果延迟能压到28ms以内，就把GR节点全迁过去。要是不行……我就再泡一杯速溶咖啡。

（编辑：站长网）

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