MySQL高可用核心是系统化设计而非工具堆砌，需围绕复制可靠性、故障检测准确性、切换可控性、连接连续性四环节构建；Orchestrator适合新部署GTID环境，MHA仅限存量低版本过渡使用。

MySQL 高可用架构通过 MHA 或 Orchestrator 实现，核心不是“装上工具就自动高可用”，而是围绕复制可靠性、故障检测准确性、切换动作可控性、客户端连接连续性四个环节系统设计。两者都依赖主从复制，但对配置、权限、网络和运维逻辑有明确且不同的要求。

Orchestrator：推荐用于新部署的主动式拓扑管理

Orchestrator 是当前活跃维护、功能更全面的方案，适合 MySQL 5.7/8.0 及 GTID 环境：

• 拓扑发现必须真实可连：所有 MySQL 实例需显式配置 report_host=真实IP（禁用 127.0.0.1 或 localhost），report_port 与实际监听端口一致；Orchestrator 是主动探测每个 IP:port，不是靠从库上报
• 元数据持久化要启用：所有节点必须设 relay_log_info_repository = TABLE 和 master_info_repository = TABLE，否则无法准确读取复制位置
• 权限与连接不能省略：orchestrator 用户需具备 REPLICATION CLIENT、PROCESS、SUPER（部分操作需要）权限；自身应部署在独立节点，避免与 MySQL 共机
• 切换前自动校验延迟：默认调用 SELECT MASTER_POS_WAIT() 等待从库追平，超时（30 秒）则跳过该节点——比 MHA 更可控，可防脑裂
• 连接重定向靠外部协同：Orchestrator 不改 DNS 或 VIP，需配合 hook 脚本完成 ip addr add 漂移或调用 DNS API 更新记录

MHA：仅限存量低版本环境，配置容错极低

MHA 已停止维护，仅建议在无法升级的 MySQL 5.6 环境中谨慎使用：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• SSH 连通≠网络通，而是密钥直连：所有节点（含 manager）必须用同一组 SSH 密钥，无密码登录彼此；禁用 ~/.ssh/config 别名或 ProxyCommand；sshd_config 中 PubkeyAuthentication yes 必须开启，PasswordAuthentication no 可接受
• 检测命令要秒级返回：manager 上执行 ssh -o ConnectTimeout=5 -o BatchMode=yes user@host 必须立即成功；用 masterha_check_ssh 比看日志更快定位哪台失败
• 切换后应用连不上是设计使然：MHA 只修改配置文件或漂移 VIP，不干预客户端行为；若未配 VIP 或 DNS 自动更新，应用仍连旧 IP 就必然失败
• 半同步是数据安全底线：必须启用 rpl_semi_sync_master_enabled=1，并设合理超时（如 1000ms），避免退化为纯异步导致丢数据

共性关键点：绕不开的基础配置

无论选哪个工具，以下几项不达标，高可用就是空谈：

• 复制状态必须健康：所有从库 SHOW SLAVE STATUS\G 中 Slave_IO_Running 和 Slave_SQL_Running 均为 YES，Seconds_Behind_Master 稳定在合理范围（如 < 5 秒）
• GTID 推荐开启：能简化故障后重搭复制关系，避免位点计算错误；Orchestrator 对 GTID 支持原生友好，MHA 需额外适配
• 监控与告警要前置：工具本身不替代监控；应接入 Prometheus + Grafana 或 Zabbix，对复制延迟、IO/SQL 线程状态、磁盘空间等做实时预警
• 切换演练不能少于季度一次：自动切换脚本、VIP 漂移、DNS 更新、应用连接池刷新等环节，必须实操验证，不能只信文档

Orchestrator 更适合现代运维场景，MHA 仅作过渡之选。真正决定高可用成败的，从来不是工具本身，而是复制链路是否健壮、网络与权限是否规范、切换后服务是否可达——工具只是把人设定的逻辑自动化执行而已。