mysql在主从复制中的自动故障转移与高可用性

来源：这里教程网时间：2026-02-28 20:40:38 作者：

MySQL 原生不支持自动故障转移，主从复制本身只是数据同步机制，不具备高可用（HA）决策能力；要实现自动故障转移，必须依赖外部工具或中间件。

MySQL 主从复制本身没有自动选主逻辑

主从复制仅保证

binlog

从主库写入、从库重放，

IO_THREAD

和

SQL_THREAD

的状态（如

Seconds_Behind_Master

）需人工监控。MySQL 不会因主库宕机而自动将某从库提升为新主，也不会自动修改其余从库的

CHANGE REPLICATION SOURCE TO

配置。

常见错误现象：
SHOW REPLICA STATUS\G
显示
Replica_IO_Running: No
或
Replica_SQL_Running: No
，但没人干预，复制就一直停着主库宕机后，应用若仍连原主地址，会直接报错
Lost connection to MySQL server
，不会“自动切到从库” 即使配置了读写分离中间件（如
ProxySQL
），它默认也不具备主库故障后的自动提主 + 重配从库能力，需额外脚本或插件支持

常用自动故障转移方案及关键差异

真正起作用的是外围组件，它们通过心跳、复制延迟、角色状态等判断是否触发切换，并执行一系列原子操作：停写、选主、重置复制拓扑、更新路由。

MHA
（Master High Availability）：Perl 编写，成熟稳定，支持在线切换和自动 failover，但依赖 SSH 和
mysqlbinlog
解析，已多年未更新，对 MySQL 8.0+ 新认证插件兼容性需验证
Orchestrator
：Go 编写，Web 界面友好，支持自动恢复、拓扑可视化、自定义钩子（如调用
curl
通知运维），但自身单点，建议配合
Consul
或
etcd
做高可用
MySQL InnoDB Cluster
（基于
Group Replication
）：官方方案，内置自动选主（
group_replication_member_expel_timeout
控制驱逐）、自动故障检测与恢复，但要求全栈使用 MySQL 5.7.17+ / 8.0+，且不兼容传统异步复制拓扑
ProxySQL + 自定义脚本
：轻量灵活，适合已有架构；需自己实现健康检查（如查
SELECT @@read_only
）、failover 流程（调用
STOP REPLICA; RESET REPLICA ALL;
等），容易遗漏
gtid_purged
同步或
relay_log_recovery
设置

自动切换中最容易被忽略的三个技术点

很多 HA 方案失败不是因为选主逻辑错，而是后续数据一致性保障没做全。

GTID 一致性：切换前必须确保所有从库已追平
Executed_Gtid_Set
，否则新主上执行的新事务可能在部分从库重复或丢失；
WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS
是安全等待的关键函数复制源重定向：新主提升后，其他从库需执行
CHANGE REPLICATION SOURCE TO SOURCE_HOST='new_master_ip'
，但
SOURCE_AUTO_POSITION=1
必须开启，否则 GTID 模式下会报错
Client requested master to start replication from position > file size
应用连接池未刷新：即使中间件切换成功，应用端的数据库连接池（如
HikariCP
中的
connection-test-query
）若缓存旧主地址或未启用
autoReconnect=true
，仍会持续报错，需配合 DNS TTL 缩短或 VIP/SDN 地址漂移

-- 示例：Orchestrator 触发 failover 后，手动验证新主 GTID 追平情况
SELECT 
  @@global.gtid_executed AS current_gtid,
  (SELECT Executed_Gtid_Set FROM performance_schema.replication_connection_status 
   WHERE Channel_Name = 'group_replication_applier') AS applier_gtid;

自动故障转移不是开个开关就能用的功能，它是一组协同动作的集合：检测、决策、执行、验证、回滚预备。任何一环缺位，都可能导致脑裂、数据丢失或服务长时间中断。最常出问题的地方，往往不在“怎么切”，而在“切完之后，数据还对不对、下游还连不连得上”。