如何实现主从自动切换_mysql故障切换思路_网络技术

MySQL主从自动切换需借助外部工具实现，核心是主库宕机时快速安全提升从库为新主，并避免脑裂、数据丢失；推荐Orchestrator、MHA等方案，须配套半同步复制、统一监控与定期演练。

MySQL 主从自动切换不是 MySQL 原生支持的功能，需借助外部工具或自建逻辑实现。核心目标是：当主库宕机时，快速、安全地将一个健康从库提升为新主库，并更新应用连接配置（或通过中间层路由），同时避免脑裂、数据丢失和重复写入。

自动切换的前提不是“只要主挂了就切”，而是满足一系列安全条件：

主库真实不可用：需排除网络闪断、临时高负载等误判；建议至少两个监控节点共同探测（如 MHA 的多节点仲裁）
候选从库数据最新：优先选 Seconds_Behind_Master = 0 且 IO/SQL 线程均运行正常的从库；若多个满足，再比对 Exec_Master_Log_Pos 和 Relay_Master_Log_File 确定最接近主库的节点
无脑裂风险：必须确保旧主库彻底离线（如通过 STONITH 或强制关机），否则可能双主写入导致数据冲突
GTID 或位点可追溯：强烈建议开启 GTID（gtid_mode=ON），便于故障后精准找主、补数据、重搭从库

不推荐纯脚本轮询 + kill process 的方式，稳定性差、边界情况多。生产环境建议以下方案：

MHA（Master High Availability）：老牌成熟方案，支持自动选主、VIP 漂移、SSH 免密操作、在线手动切换；缺点是依赖 Perl、维护渐少，但稳定可用
Orchestrator：Go 编写，Web 界面友好，支持自动故障转移、拓扑发现、集群分组、人工干预开关；可对接 Consul/Etcd 实现服务发现
ProxySQL + 自动化脚本：利用 ProxySQL 的 hostgroup 主从权重+健康检查，配合外部脚本监听 failover 事件，调用 mysql -e "STOP SLAVE; RESET SLAVE ALL;" 等命令完成角色调整，再刷新 ProxySQL 配置
基于 Kubernetes 的 Operator（如 PressLabs MySQL Operator）：云原生场景首选，自动管理 StatefulSet、PVC、主从关系、备份恢复，内置切换逻辑

实际切换过程不是“一键”，而是分阶段可控执行：

探测阶段：Orchestrator 每秒检测主库心跳（默认通过普通账号执行 SELECT 1），连续失败 N 次触发判断
分析阶段：扫描所有从库，过滤掉延迟大、SQL 线程异常、版本不兼容的节点，选出最优候选（支持自定义权重）
切换阶段：停止候选从库复制 → 执行 STOP SLAVE; RESET SLAVE ALL; → 将其设为只读关闭 → 更新其 read_only=OFF → 在其他从库上执行 CHANGE MASTER TO ... 指向新主
通知与收敛：发送 Slack/邮件告警；更新 DNS 记录或配置中心（如 Nacos）中的数据库地址；可回调自定义脚本（如刷新应用连接池）

没有这些，自动切换反而放大故障：

半同步复制（Semisync）开启：保证主库提交事务前至少一个从库已收到 relay log，降低切换时的数据丢失概率（rpl_semi_sync_master_enabled=ON）
统一监控告警体系：Zabbix/Promet
heus + Grafana 监控复制延迟、线程状态、磁盘空间、连接数，异常时联动 Orchestrator 或人工介入
定期演练与日志审计：每月至少一次模拟主库 kill -9，验证切换耗时（建议 ≤ 30 秒）、数据一致性（用 pt-table-checksum 校验）、应用是否自动重连
应用层适配：连接串不要写死 IP；使用支持重连+读写分离的驱动（如 MySQL Connector/J 的 autoReconnect=true&failOverReadOnly=false）；或统一走中间件（ShardingSphere、MyCat）屏蔽底层变化