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

MySQL原生不支持自动故障转移,必须依赖MHA、Orchestrator、InnoDB Cluster或ProxySQL等外部组件实现;切换成功的关键在于GTID一致性、复制源重定向和应用连接池刷新。

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

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

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

主从复制仅保证 binlog 从主库写入、从库重放,IO_THREADSQL_THREAD 的状态(如 Seconds_Behind_Master)需人工监控。MySQL 不会因主库宕机而自动将某从库提升为新主,也不会自动修改其余从库的 CHANGE REPLICATION SOURCE TO 配置。

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

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

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

Lessie AI

Lessie AI

一款定位为「People Search AI Agent」的AI搜索智能体

下载

  • MHA(Master High Availability):Perl 编写,成熟稳定,支持在线切换和自动 failover,但依赖 SSH 和 mysqlbinlog 解析,已多年未更新,对 MySQL 8.0+ 新认证插件兼容性需验证
  • Orchestrator:Go 编写,Web 界面友好,支持自动恢复、拓扑可视化、自定义钩子(如调用 curl 通知运维),但自身单点,建议配合 Consuletcd 做高可用
  • 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;

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

https://www.php.cn/faq/1987044.html

发表回复

Your email address will not be published. Required fields are marked *