MySQL 高可用方案MHA与Orchestrator

高可用是数据库架构的核心要求，MHA 和 Orchestrator 是 MySQL 最常用的两种方案。

MHA（Master High Availability）

架构原理

ini

                    ┌──────────────┐
                    │   MHA Manager │
                    │  (监控+切换)   │
                    └──────┬───────┘
                           │ 监控
          ┌────────────────┼────────────────┐
          │                │                │
    ┌─────┴─────┐    ┌─────┴─────┐    ┌─────┴─────┐
    │  Master   │───▶│  Slave1   │    │  Slave2   │
    │ (主库)    │复制│  (从库)   │复制│  (从库)   │
    └───────────┘    └───────────┘    └───────────┘

核心组件：

MHA Manager：监控主库健康，协调故障切换
MHA Node：运行在每个 MySQL 节点上，执行具体切换脚本

故障切换流程

Bash

1. 检测主库故障（连续3次心跳失败）
         ↓
2. 确认主库宕机
         ↓
3. 从各从库读取最新 binlog 位置
         ↓
4. 选择数据最新的从库作为新主库
         ↓
5. 其他从库补齐差异数据（relay log）
         ↓
6. 提升新主库，配置其他从库复制
         ↓
7. 可选：VIP 漂移或 DNS 切换
         ↓
8. 发送告警通知

部署配置

配置文件：/etc/mha/app1.cnf

Bash

[server default]
# Manager 配置
manager_workdir=/var/log/mha/app1
manager_log=/var/log/mha/app1/manager.log

# SSH 配置（免密登录）
ssh_user=root
ssh_port=22

# MySQL 用户
user=mha
password=mha_password

# 复制用户
repl_user=repl
repl_password=repl_password

# 切换脚本
master_ip_failover_script=/usr/local/bin/master_ip_failover
shutdown_script=""
report_script=/usr/local/bin/send_report

# 检测间隔（秒）
ping_interval=3

[server1]
hostname=192.168.1.101
port=3306
candidate_master=1

[server2]
hostname=192.168.1.102
port=3306
candidate_master=1

[server3]
hostname=192.168.1.103
port=3306
no_master=1

VIP 切换脚本：master_ip_failover

JSON

#!/usr/bin/env perl
use strict;
use warnings FATAL => 'all';

my $vip = '192.168.1.100/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ip addr add $vip dev eth0";
my $ssh_stop_vip = "/sbin/ip addr del $vip dev eth0";

sub start_vip {
    my $output = `$ssh_start_vip 2>&1`;
}

sub stop_vip {
    my $output = `$ssh_stop_vip 2>&1`;
}

MHA 常用命令

Bash

# 检查 SSH 免密登录
masterha_check_ssh --conf=/etc/mha/app1.cnf

# 检查复制状态
masterha_check_repl --conf=/etc/mha/app1.cnf

# 启动监控
masterha_manager --conf=/etc/mha/app1.cnf

# 手动切换（主库正常时）
masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=alive

# 手动切换（主库故障时）
masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=dead

MHA 优缺点

优点	缺点
切换时间短（10-30秒）	不支持 GTID（需额外处理）
数据丢失最少	开源版已停止维护
配置灵活	需 SSH 免密
支持在线切换	仅支持一主多从

Orchestrator

架构原理

Bash

┌─────────────────────────────────────────┐
│           Orchestrator                    │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐   │
│  │ Web UI  │  │  API    │  │  后端存储│   │
│  └─────────┘  └─────────┘  └────┬────┘   │
└────────────────────────────────┼────────┘
                                 │
        ┌────────────────────────┼────────────────────────┐
        │                        │                        │
  ┌─────┴─────┐           ┌──────┴─────┐          ┌──────┴─────┐
  │  Master   │◀─────────│  Replica1  │          │  Replica2  │
  └───────────┘   复制    └────────────┘          └────────────┘

核心特性：

拓扑感知：自动发现复制拓扑
伪 GTID：无需 GTID 也能精确定位
多后端存储：支持 MySQL、SQLite、PostgreSQL
Web UI：可视化管理和操作
Hook 机制：可扩展自动化脚本

故障切换流程

text

1. 连续探测失败（默认多次）
         ↓
2. 确认主库不可达
         ↓
3. 分析复制拓扑，选择最佳候选
         ↓
4. 验证候选主库数据最新
         ↓
5. 原子切换：重构复制关系
         ↓
6. 调用 Hook 脚本（通知、VIP等）
         ↓
7. 记录切换历史

部署配置

配置文件：/etc/orchestrator.conf.json

text

{
  "ListenAddress": ":3000",
  "MySQLTopologyUser": "orchestrator",
  "MySQLTopologyPassword": "orchestrator_password",
  "BackendDB": "mysql",
  "MySQLOrchestratorHost": "127.0.0.1",
  "MySQLOrchestratorPort": 3306,
  "MySQLOrchestratorDatabase": "orchestrator",
  "MySQLOrchestratorUser": "orchestrator",
  "MySQLOrchestratorPassword": "orchestrator_password",

  "RecoveryPeriodBlockMinutes": 60,
  "RecoveryIgnoreHostnameFilters": [],
  "RecoverMasterClusterFilters": ["*"],

  "PostFailoverProcesses": [
    "/usr/local/bin/failover_hook.sh {failureType} {failedHost} {failureCluster} {successorHost}"
  ],

  "PostMasterFailoverProcesses": [
    "/usr/local/bin/master_failover_hook.sh {failedHost} {successorHost}"
  ],

  "PseudoGTIDPattern": "drop view if exists `_pseudo_gtid_`",
  "DetectPseudoGTIDQuery": "show global status like 'PseudoGTIDStatus'"
}

故障切换 Hook 脚本

text

#!/bin/bash
# /usr/local/bin/master_failover_hook.sh

FAILED_HOST=$1
SUCCESSOR_HOST=$2

# VIP 漂移
ssh root@$FAILED_HOST "ip addr del 192.168.1.100/24 dev eth0"
ssh root@$SUCCESSOR_HOST "ip addr add 192.168.1.100/24 dev eth0"

# DNS 更新
nsupdate <<EOF
update delete db-master.example.com A
update add db-master.example.com 300 A $SUCCESSOR_HOST
send
EOF

# 告警通知
curl -X POST "https://hook.example.com/alert" \
  -d "{\"text\": \"MySQL Failover: $FAILED_HOST -> $SUCCESSOR_HOST\"}"

Orchestrator 常用命令

text

# 发现实例
orchestrator -c discover -i 192.168.1.101:3306

# 查看拓扑
orchestrator -c topology -i 192.168.1.101:3306

# 手动切换主库
orchestrator -c repoint -i 192.168.1.102:3306

# 故障恢复
orchestrator -c recover -i 192.168.1.101:3306

# 重置恢复周期
orchestrator -c reset-recovery-period -i 192.168.1.101:3306

Web UI 操作

访问 http://orchestrator-host:3000

功能	说明
Clusters	查看所有集群
Topology	可视化复制拓扑
Audit	操作审计日志
Agents	节点健康状态
Failover	手动/自动切换

Orchestrator 优缺点

优点	缺点
支持非 GTID 模式	学习曲线较陡
活跃开发维护	依赖较多组件
Web UI 可视化	配置相对复杂
支持多数据中心	切换时间略长
伪 GTID 精确定位	需要额外存储

方案对比

特性	MHA	Orchestrator
开发状态	停止维护	活跃开发
GTID 支持	需额外处理	原生支持
非 GTID 支持	支持	支持（伪 GTID）
Web UI	无	有
切换速度	10-30秒	30-60秒
配置复杂度	简单	较复杂
多集群管理	不支持	支持
扩展性	脚本	Hook 机制

选型建议

场景	推荐方案
传统架构、快速上线	MHA
非 GTID 环境	Orchestrator
多集群统一管理	Orchestrator
需要可视化运维	Orchestrator
已有 GTID 环境	Orchestrator
追求最快切换	MHA

要点总结

MHA：轻量级、切换快、配置简单，适合快速部署
Orchestrator：功能全面、可视化、活跃维护，适合现代架构
切换流程：检测故障 → 选新主 → 数据同步 → 切换完成
VIP 管理：故障切换后需自动漂移 VIP 或更新 DNS
监控告警：切换后必须发送通知，确保运维感知

📝 发现内容有误？点击此处直接编辑