主从复制是mysql高可用基石但默认异步有丢数据风险；gtid+半同步可提升一致性；mha已停更，orchestrator更现代；proxysql等proxy层实现读写分离与故障屏蔽。
主从复制是 MySQL 高可用的基石，但默认异步复制有数据丢失风险
MySQL 单实例故障即服务中断，必须依赖外部机制实现高可用。主从复制（replication）是最基础、最广泛使用的方案，但默认的异步模式下，主库提交事务后不等待从库确认就返回成功，一旦主库宕机且未同步的日志尚未落盘到从库，就会丢数据。
实际部署中需明确三点：
- 启用
sync_binlog=1和innodb_flush_log_at_trx_commit=1降低主库单点丢失概率 - 从库开启
relay_log_recovery=ON，避免 crash 后 relay log 不一致 - 监控
Seconds_Behind_Master和SHOW REPLICA STATUS中的IO_Running/SQL_Running状态，不能只看“yes”
GTID + 半同步复制能显著提升主从一致性与故障切换可靠性
传统基于 binlog 文件名和 position 的复制在主库切换或网络抖动时极易配错位置；而 GTID（global transaction identifier）为每个事务分配唯一 ID，让复制关系可自动定位、去重、跳过已执行事务。
半同步复制（rpl_semi_sync_master_enabled）要求至少一个从库写入 relay log 并刷盘后，主库才返回客户端成功。它不是强一致，但大幅压缩了数据丢失窗口。
关键配置注意：
- 必须同时启用
gtid_mode=ON和enforce_gtid_consistency=ON，否则启动失败 - 半同步插件需在主从两端都安装（
semisync_master.so/semisync_slave.so），且从库也要启用rpl_semi_sync_slave_enabled -
rpl_semi_sync_master_timeout建议设为 1000000（1秒），避免主库因等待超时退化为异步
MHA 和 Orchestrator 是成熟可靠的自动故障转移方案，但 MHA 已停止维护
MySQL 自身不提供自动主从切换能力，必须依赖第三方工具。MHA（Master High Availability）曾是主流选择，支持快速 failover、在线切换、binlog 补偿，但官方自 2020 年起不再更新，perl 编写也带来运维门槛。
Orchestrator 更现代，Go 编写、Web ui 友好、支持拓扑发现与自动化修复，且兼容 GTID 和多级复制。它通过定期调用 SHOW REPLICA STATUS 和 select MASTER_POS_WAIT() 判断节点状态，比仅靠心跳更准确。
部署前务必验证：
- 所有节点 ssh 免密互通（Orchestrator 需执行远程命令）
- 被管理实例需开放
PROCESS和REPLICATION CLIENT权限 - 避免将 Orchestrator backend（如 MySQL）部署在被管理集群内，否则故障时可能全链路失效
Proxy 层（如 ProxySQL、MaxScale）是读写分离与故障屏蔽的关键一环
应用直连数据库 IP 会导致故障转移后连接中断、DNS 缓存问题、读写路由错误。Proxy 层位于应用和 MySQL 之间，承担连接池、SQL 路由、健康检查、自动摘除异常节点等职责。
ProxySQL 是当前最常用的选择：它支持按规则匹配 SELECT 发往从库、自动识别主从角色变更、甚至缓存查询结果。但要注意：
- 其内部健康检查默认基于
PING，对主从延迟敏感的场景需配合mysql_replication_hostgroups和延迟阈值配置 - 配置变更需执行
LOAD MYSQL SERVERS TO RUNTIME+SAVE MYSQL SERVERS TO DISK才真正生效 - 不要把
mysql_users密码明文写进配置文件，应使用UPDATE mysql_users SET password=ENCRYPT('xxx')加密存储
真正难的不是搭起一套高可用架构，而是让每一层的健康检查逻辑对齐、超时设置不打架、failover 后的应用连接恢复不超时——这些细节往往在压测或真实故障时才暴露。