MySQL 高可用 MHA 与 Orchestrator

摘要：MHA 是经典的 Perl 脚本方案，Orchestrator 是目前更常用的 Go 语言拓扑管理工具，支持自动故障检测、可视化拓扑与命令行切换。本文以 Orchestrator 为主，覆盖部署、切换与演练。

适用环境

bash

# 至少一主两从的复制拓扑（切换需要有候选从库）
mysql -uroot -p -e "SHOW REPLICA STATUS\G" | grep -E 'Master_Host|Running|Behind'

# 确认 GTID 开启（Orchestrator 切换依赖 GTID 更可靠）
mysql -uroot -p -e "SELECT @@gtid_mode, @@enforce_gtid_consistency;"

操作步骤

1. 安装 Orchestrator

bash

# 下载对应发行版的 rpm/deb 包并安装（以包名为准）
sudo rpm -ivh orchestrator-*.rpm
# 或直接用二进制
/usr/local/orchestrator/orchestrator --version

2. 配置被管实例账号

sql

-- 每个 MySQL 实例上都创建，供 Orchestrator 发现拓扑用
CREATE USER 'orc_client'@'%' IDENTIFIED BY 'OrcPass!2026';
GRANT SUPER, PROCESS, REPLICATION SLAVE, REPLICATION CLIENT, RELOAD ON *.* TO 'orc_client'@'%';
GRANT SELECT ON mysql.slave_master_info TO 'orc_client'@'%';

3. 配置 Orchestrator（/usr/local/orchestrator/orchestrator.conf.json 关键项）

json

{
  "MySQLTopologyUser": "orc_client",
  "MySQLTopologyPassword": "OrcPass!2026",
  "MySQLTopologyUseMutualTLS": false,
  "RecoveryPeriodBlockSeconds": 300,
  "ApplyMySQLPromotionAfterMasterFailover": true
}

4. 启动并发现实例

bash

sudo systemctl enable --now orchestrator
# Web 界面默认 3000 端口，命令行发现实例
/usr/local/orchestrator/orchestrator-client -c discover -i 10.0.1.11:3306
/usr/local/orchestrator/orchestrator-client -c topology -i 10.0.1.10:3306

5. 手动切换演练（先在演练环境做熟）

bash

# 优雅切换：把 10.0.1.11 提升为新主
orchestrator-client -c graceful-master-takeover -i 10.0.1.10:3306 -d 10.0.1.11:3306
orchestrator-client -c topology -i 10.0.1.11:3306

危险

故障切换会改写复制拓扑并可能造成少量数据丢失（异步复制下未传到从库的 binlog 会丢）。切换前必须确认业务可接受，并保留旧主现场以便补数据。

6. 脑裂与误切换防护

配置 RecoveryPeriodBlockSeconds，避免短时间内反复自动切换。
自动切换策略只在明确演练过的环境开启；多数团队选择「自动检测 + 人工确认切换」。
切换后及时更新应用连接配置或代理层（如 ProxySQL）的写节点。

验证

bash

# 1. 拓扑中主库已变更
orchestrator-client -c topology -i 10.0.1.11:3306

# 2. 新主可写，其余从库复制正常
mysql -uroot -p -h 10.0.1.11 -e "INSERT INTO shopdb.t_probe VALUES (2, NOW());"
mysql -uroot -p -h 10.0.1.12 -e "SELECT * FROM shopdb.t_probe;"

常见坑

WARNING

MHA 已多年未活跃维护，新项目建议选用 Orchestrator 或 MySQL InnoDB Cluster；老集群迁移前先评估。

WARNING

Orchestrator 自身的后端 MySQL 也要做高可用，否则它挂了就没人做切换。

DANGER

网络抖动会导致 Orchestrator 误判主库宕机。务必多机房部署 Orchestrator 节点并采用 raft 模式，避免单点误判引发无谓切换。

MySQL 高可用 MHA 与 Orchestrator ​

适用环境 ​

操作步骤 ​

验证 ​

常见坑 ​

参考资料 ​

MySQL 高可用 MHA 与 Orchestrator

适用环境

操作步骤

验证

常见坑

参考资料