为什么需要MySQL主备自动切换？
在云服务器上运行MySQL数据库时，单点故障是企业面临的最大风险之一。一旦主数据库宕机，整个业务系统可能陷入瘫痪，造成不可估量的损失。通过配置MySQL主备自动切换（Failover），可以在主库故障时自动将备库提升为主库，实现业务的快速恢复，将停机时间从小时级缩短到秒级。
本文将详细介绍如何从零搭建一套可靠的MySQL主备自动切换方案。
一、搭建主从复制架构
主备自动切换的前提是主从复制已经正确配置。以下是关键步骤：
1.1 主库配置
在主数据库的 my.cnf 中添加以下配置：
[mysqld]
server-id = 1
log-bin = mysql-bin
binlog-format = ROW
expire_logs_days = 7
重启MySQL后，创建复制用户：
CREATE USER 'repl'@'%' IDENTIFIED BY '强密码';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
1.2 从库配置
在从数据库的 my.cnf 中配置：
[mysqld]
server-id = 2
relay-log = relay-bin
read-only = 1
log-bin = mysql-bin
log-slave-updates = 1
然后执行主从连接命令，确保数据同步正常。
1.3 验证复制状态
| 检查项 | 命令 | 期望结果 |
|---|---|---|
| 主库Binlog | SHOW MASTER STATUS; |
File和Position有值 |
| 从库IO线程 | SHOW SLAVE STATUS\G |
Slave_IO_Running: Yes |
| 从库SQL线程 | SHOW SLAVE STATUS\G |
Slave_SQL_Running: Yes |
| 复制延迟 | Seconds_Behind_Master |
0或接近0 |
二、健康监控方案
自动切换的基础是准确的健康检测。监控维度和告警阈值如下：
- 进程存活检测：每5秒检查MySQL进程是否运行
- 连接可用性：尝试建立连接并执行简单查询（如
SELECT 1） - 复制延迟：延迟超过10秒触发告警，超过60秒视为异常
- 磁盘空间：数据盘使用率超过85%告警
- 慢查询：30秒内慢查询超过5条触发关注
推荐使用以下监控工具组合：
| 工具 | 用途 | 优势 |
|---|---|---|
| Prometheus + Grafana | 指标采集与可视化 | 生态丰富，告警灵活 |
| Orchestrator | MySQL拓扑管理 | 自动发现，可视化拓扑 |
| MHA | 主备切换 | 成熟稳定，数据安全 |
三、自动切换脚本实现
核心切换逻辑伪代码如下：
def check_master_health():
"""检测主库是否健康"""
try:
conn = mysql.connect(host=master_host, timeout=3)
conn.execute("SELECT 1")
# 检查复制延迟
delay = get_replication_delay()
return delay < 60
except:
return False
def perform_failover():
"""执行故障切换"""
# 1. 确认主库确实不可用（多次重试）
for i in range(3):
if check_master_health():
return # 主库恢复，取消切换
# 2. 选择最优从库（延迟最低、数据最新）
best_slave = select_best_slave()
# 3. 停止从库复制
stop_slave(best_slave)
# 4. 提升从库为主库
promote_to_master(best_slave)
# 5. 更新其他从库指向新主库
redirect_slaves(best_slave)
# 6. 更新VIP或DNS（让应用自动连接新主库）
update_vip(best_slave)
# 7. 发送通知
send_alert("主备切换完成", f"新主库: {best_slave}")
四、VIP漂移与DNS切换
切换后，应用程序需要知道新的主库地址。有两种主流方案：
方案对比
| 方案 | 切换速度 | 实现复杂度 | 适用场景 |
|---|---|---|---|
| VIP漂移 | 1-3秒 | 中 | 同一子网内 |
| DNS切换 | 30-120秒 | 低 | 跨网段场景 |
| 代理层（ProxySQL/MySQL Router） | 1-5秒 | 高 | 大规模集群 |
推荐方案：同机房部署使用VIP漂移，跨机房使用代理层。
五、安全性配置要点
自动切换涉及权限变更，安全配置不可忽视：
- 网络隔离：复制和切换流量走内网，不暴露公网
- SSL加密：主从复制启用SSL连接，防止中间人攻击
- 访问控制：切换脚本使用最小权限原则，避免root直连
- 审计日志：记录所有切换操作的完整日志，便于回溯
- 双因素确认：关键操作（如手动切换）需要二次确认
六、测试与演练
再完善的方案也需要定期验证。建议的测试计划：
- 月度演练：在非高峰期模拟主库宕机，验证自动切换
- 指标记录：记录RTO（恢复时间目标）和RPO（恢复点目标）
- 数据校验：切换后使用
pt-table-checksum校验数据一致性 - 回滚测试：验证旧主库恢复后能否重新加入集群
- 混乱工程：随机拔网线、杀进程，测试极端场景
七、故障恢复与回切
主库修复后，不要急于回切，应按以下步骤操作：
- 在旧主库上配置为从库，同步新主库数据
- 验证数据完全一致
- 在业务低峰期执行计划内回切
- 回切后再次验证所有复制链路正常
总结
MySQL主备自动切换是保障数据库高可用的关键能力。核心要点包括：可靠的监控检测、原子化的切换脚本、合理的VIP/代理方案、严格的安全策略，以及持续的测试演练。建议从MHA或Orchestrator等成熟方案入手，逐步完善适合自身业务的切换体系，切忌从零手写而不经过充分测试。