MySQL高可用架构选型与MHA高可用切换实践

MySQL高可用架构是数据库运维的核心工程。主从复制能做到数据冗余，但主库故障时，从库晋升需要手动操作，RTO（恢复时间目标）不可控。要让数据库在故障时自动切换、快速恢复，需要在高可用架构上做文章。本文对比常用高可用方案，并给出基于MHA（Master High Availability）的主从切换实践。

MySQL高可用架构的三种形态

方案一：主从复制+手动切换。部署简单，但故障后要人工介入，RTO以分钟计。方案二：主从+MHA自动切换。MHA在从库中选择最优从库提升为主库，自动处理切换，RTO控制在10-30秒，适合中小规模。方案三：主从+半同步+一主多从架构，适合高可用和数据中心。方案四：结合组复制（MGR）或PXC实现多主读写，架构复杂，适合金融级场景。

选型原则：业务中断可容忍时长决定方案。30秒以上选择主从+MHA；30秒以下选择MGR；要求多中心跨机房，用MGR+跨机房方案。

MHA切换机制

MHA的核心是把主库上的binlog传给候选从库，保证数据不丢失，再让候选从库晋升为主库，最后把其他从库重新指向新主库。流程分四步：确认故障主库、在最优从库上补全binlog、提升新主库、重定向从库连接。

MHA检测节点与切换管理器分离：Manager定期检测主库和从库状态，检测到主库无响应，Manager执行切换脚本。部署MHA时需要manager节点、配置主从关系，并确保各节点SSH互信。

MHA部署核心配置

先做好主从复制（relay log、gtid或binlog），然后在manager节点配置conf文件：

[server default]manager_workdir=/opt/mhalog=/opt/mha/mha.logmaster_ip_failover_script=/opt/mha/master_ip_failover
[server1]hostname=192.168.1.10candidate_master=1
[server2]hostname=192.168.1.11candidate_master=1
[server3]hostname=192.168.1.12no_master=1

其中master_ip_failover脚本负责VIP迁移，当主库故障时把VIP从旧主库迁移到新主库，业务侧无感知。

读写分离与故障转移验证

高可用架构部署后，需要做故障演练。用kill命令杀掉主库MySQL进程，观察MHA是否在10秒内完成切换：

kill -9 $(pgrep -f mysqld)watch -n 2 'mysql -h 192.168.1.100 -e "select @@hostname"'

切换完成后，业务写流量自动指向新主库，从库继续服务只读请求。切换前建议把从库升级为候选主库时打开半同步，减少数据丢失风险。

架构演进与监控告警

MHA的局限是架构节点（manager）单点，生产环境再叠加监控：数据库层监控（连接数、慢查询、复制延迟），系统层监控（CPU、磁盘、网络），触发阈值后自动告警。数据量上来后，把MHA迁移到MGR（MySQL Group Replication）或一套PXC上，配合哨兵做高可用，再考虑跨机房级容灾。

高可用架构没有银弹，核心是用最适配的方案把RTO打下来，把切换流程自动化，并通过故障演练持续验证切换脚本的有效性。数据库高可用切换流程，从选型到验证，落到运维动作里，才能避免故障发生时手忙脚乱。