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

去年十月，我接手了一个电商平台的数据库升级项目——把单节点MySQL换成自动容灾架构。原系统用的是单实例，每天峰值QPS 8000+，凌晨偶尔会卡顿5-10秒，运维同事说“这已经算稳定了”。但老板不这么想——去年双十一前夜，因为机房断电，系统挂了2小时，直接损失几十万订单。这成了我必须解决的技术债。

选型时纠结过：是直接上云厂商的RDS高可用版，还是自己搭MHA+Keepalived？前者省事但黑盒，后者可控但麻烦。最后选了后者——因为我想试试新技术：用ProxySQL做读写分离，结合Orchestrator做自动故障转移。为什么不用MHA？MHA的切换依赖SSH，而ProxySQL能直接感知主库状态，延迟更低——实测数据：主库宕机后，ProxySQL在3秒内把流量切到备库，而MHA需要15秒（包括SSH登录和脚本执行时间）。

搭建过程踩了个大坑：Orchestrator的拓扑发现功能。它默认会扫描所有可能的MySQL实例，结果把测试环境的库也拉进了集群，导致主备切换时误操作。后来在配置里加了`"DetectClusterQuorum": false`和`"PeerURLs": []`，才把范围锁死。这细节别人很少写——多数教程只说“安装Orchestrator”，但没说怎么限制它的扫描范围。

测试阶段更刺激：我故意kill掉主库的mysqld进程，结果备库没自动提升为主库。查日志发现，备库的`semi_sync_master_enabled`没开——Orchestrator检测到主库失联后，会检查备库的半同步状态，如果备库没开，就认为“数据不一致”，拒绝切换。这设计挺聪明，但容易忽略。后来在所有备库上加了`semi_sync_master_enabled=1`，再测试就正常了：主库宕机后，备库3秒内接管，ProxySQL同步更新路由，应用层无感知。

文章配图，仅供参考

新技术的好处不止是快。比如ProxySQL的查询缓存：我们把高频的商品查询SQL加到缓存里，QPS从8000涨到12000，响应时间从200ms降到50ms。这比加机器划算多了——一台4核8G的云服务器，每月成本3000块，而ProxySQL是开源的，0成本。

但也有局限：自动容灾不等于万无一失。比如去年双十一前，我们做了全链路压测——模拟主库宕机、网络分区、磁盘损坏等场景。结果发现：如果主库的磁盘坏了，但mysqld进程没挂（比如只是IO错误），Orchestrator不会触发切换，因为它的健康检查是基于进程状态的。这时候需要人工介入——这算个漏洞，但暂时没找到更好的办法。

下一步打算试试Group Replication——MySQL官方的高可用方案，据说能解决GTID同步延迟的问题。不过听说配置更复杂，得先在测试环境跑通。你呢？如果也在搞MySQL高可用，不妨试试ProxySQL+Orchestrator——这组合比MHA新，但实测真香。

（编辑：应用网_阳江站长网）

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