利用Orchestrator Hook实现MySQL高可用切换与VIP管理

在MySQL主从集群的运维中，Orchestrator是一款强大的拓扑管理与故障转移工具，能自动检测主库故障并完成从库晋升。但实际生产中，故障转移往往需伴随额外操作（如VIP迁移、DNS更新），此时Orchestrator Hook便可发挥作用------通过自定义脚本实现故障后的自动化扩展操作。本文将详细讲解如何配置Orchestrator Hook，并验证MySQL集群的高可用切换效果。

一、准备阶段：为Hook配置铺垫基础环境

在配置Hook前，需完成参数优化、VIP配置与机器互信，确保后续切换流程顺畅。

1.1 修改Orchestrator核心参数

目的：避免旧主库重启后自动恢复为主，导致集群频繁切换。
操作主机 ：184.151、184.152、184.153（Orchestrator集群节点）
步骤：

编辑Orchestrator配置文件：

bash 复制代码

vim /usr/local/orchestrator/conf/orchestrator.conf.json

搜索参数MasterFailoverDetachReplicaMasterHost，将其值设为true。
- 原理：故障转移时，新主库会执行reset slave，彻底清空与旧主的复制关系；旧主恢复后需手动加入集群，避免自动抢占主库角色。

1.2 为主库配置VIP（虚拟IP）

目的：对外提供统一访问入口，故障切换时仅需迁移VIP，无需修改应用连接地址。
操作主机 ：184.155（初始主库，主机名maria-05）
步骤：

查看网卡名称（确保后续VIP绑定到正确网卡）：
bash 复制代码
```
ip a
```
- 示例结果：网卡名为ens33（对应截图中网卡信息展示）。
绑定VIP到ens33网卡：
bash 复制代码
```
ip addr add 192.168.184.200/24 dev ens33
```
- 验证：再次执行ip a，可看到ens33网卡已新增192.168.184.200地址。

1.3 建立Orchestrator与MySQL机器的SSH互信

目的：Orchestrator需通过SSH远程操作MySQL节点（如执行VIP迁移脚本），互信可避免手动输入密码。
操作主机 ：184.151、184.152、184.153（Orchestrator节点）
步骤：

配置主机名映射（简化SSH连接）：
bash 复制代码
```
vim /etc/hosts
```
- 添加MySQL节点映射（如192.168.184.155 maria-05、192.168.184.156 maria-06、192.168.184.157 maria-07）。

生成SSH密钥并分发到所有MySQL节点：

bash 复制代码

# 生成密钥（一路回车默认配置）
ssh-keygen
# 分发密钥到MySQL节点
ssh-copy-id root@maria-05
ssh-copy-id root@maria-06
ssh-copy-id root@maria-07
# 验证互信（无需密码即可登录）
ssh root@maria-05

二、配置Orchestrator Hook：实现故障后自动化操作

Hook的核心是通过PostFailoverProcesses参数指定故障转移后执行的脚本，本文以"VIP自动迁移"为例配置Hook。

2.1 修改Orchestrator配置文件

操作主机 ：184.151、184.152、184.153
步骤：

编辑配置文件，定位PostFailoverProcesses参数：
bash 复制代码
```
vim /usr/local/orchestrator/conf/orchestrator.conf.json
```

配置故障后执行的命令（日志记录+VIP迁移脚本）：

json 复制代码

"PostFailoverProcesses": [
  "echo '(for all types) Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}' >> /tmp/recovery.log",
  "/usr/local/orchestrator/shell/orch_hook.sh {failureType} {failureClusterAlias} {failedHost} {successorHost} >> /tmp/orch.log"
]

变量说明：{failureType}（故障类型，如DeadMaster）、{failedHost}（故障主库）、{successorHost}（新主库）。

2.2 重启Orchestrator使配置生效

操作主机 ：184.151、184.152、184.153（依次执行，避免集群中断）
步骤：

查找Orchestrator进程ID：
bash 复制代码
```
ps -ef | grep orch
```

杀死旧进程并重启（指定配置文件与日志路径）：

bash 复制代码

kill [Orchestrator进程ID]
nohup /usr/local/orchestrator/orchestrator -config /usr/local/orchestrator/conf/orchestrator.conf.json http >> /usr/local/orchestrator/log/orchestrastor.log 2>&1 &

2.3 编写VIP迁移Hook脚本

目的：故障转移时，自动从旧主库删除VIP，在新主库添加VIP。
操作主机 ：184.151、184.152、184.153（脚本需在所有Orchestrator节点同步）
步骤：

创建脚本目录并编写脚本：

bash 复制代码

# 创建目录
mkdir -p /usr/local/orchestrator/shell
cd /usr/local/orchestrator/shell
# 编写脚本
vim orch_hook.sh

脚本内容（含注释说明）：

bash 复制代码

#!/bin/bash
# 接收Orchestrator传递的参数
FAILURE_TYPE=$1       # 故障类型（如DeadMaster）
CLUSTER_ALIAS=$2      # 集群别名
FAILED_HOST=$3        # 故障主库主机名
SUCCESSOR_HOST=$4     # 新主库主机名

# 配置VIP与网卡（需与实际环境匹配）
VIP='192.168.184.200'
INTERFACE='ens33'
# 日志文件（便于排查问题）
LOG_FILE="/tmp/vip_migration.log"

# 定义VIP添加/删除函数
update_vip() {
    local host=$1
    local action=$2  # add（添加）/ del（删除）
    echo "$(date): 开始在$host上$action VIP($VIP)" >> $LOG_FILE
    # SSH远程执行VIP操作
    ssh root@$host "ip addr $action $VIP/24 dev $INTERFACE" 2>>$LOG_FILE
    # 检查执行结果
    if [ $? -eq 0 ]; then
        echo "$(date): $host上$action VIP成功" >> $LOG_FILE
    else
        echo "$(date): $host上$action VIP失败" >> $LOG_FILE
    fi
}

# 主逻辑：仅处理主库故障（DeadMaster）
echo "$(date): Orchestrator Hook触发，故障类型：$FAILURE_TYPE" >> $LOG_FILE
if [ "$FAILURE_TYPE" == "DeadMaster" ]; then
    update_vip $FAILED_HOST "del"   # 旧主库删除VIP
    update_vip $SUCCESSOR_HOST "add"# 新主库添加VIP
else
    echo "$(date): 非主库故障，无需操作VIP" >> $LOG_FILE
fi

给脚本添加可执行权限：
bash 复制代码
```
chmod +x orch_hook.sh
```

三、高可用测试：验证Hook与切换效果

通过模拟主库故障、手动调整拓扑，验证Orchestrator Hook的自动化能力与集群可用性。

3.1 准备测试环境：编写数据写入程序

目的：实时观察故障切换时数据写入是否中断，验证高可用效果。
工具：Go语言（需提前安装go-sql-driver依赖）
步骤：

创建测试用户与表（在初始主库184.155执行）：

sql 复制代码

-- 创建读写用户
CREATE USER 'go_rw'@'%' IDENTIFIED WITH mysql_native_password BY 'Ud7q_dac8';
GRANT INSERT,DELETE,SELECT,UPDATE ON maria.* TO 'go_rw'@'%';
-- 创建测试表
USE maria;
CREATE TABLE user_info (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255),
    age INT,
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

编写Go程序（每隔1秒写入一条数据）：

go 复制代码

package main

import (
    "database/sql"
    "fmt"
    "time"
    _ "github.com/go-sql-driver/mysql" // MySQL驱动
)

func main() {
    // 连接数据库（IP为VIP：192.168.184.200）
    db, err := sql.Open("mysql", "go_rw:Ud7q_dac8@tcp(192.168.184.200)/maria")
    if err != nil {
        panic(err.Error())
    }
    defer db.Close()

    // 循环写入数据
    for {
        currentTime := time.Now().Format("2006-01-02 15:04:05")
        name := "TestUser"
        age := 25
        // 执行插入
        _, err := db.Exec("INSERT INTO user_info (name, age, created_at) VALUES (?, ?, ?)", name, age, currentTime)
        if err != nil {
            fmt.Printf("%s: 写入失败：%v\n", currentTime, err)
        } else {
            fmt.Printf("%s: 写入成功\n", currentTime)
        }
        time.Sleep(1 * time.Second) // 每隔1秒执行一次
    }
}

运行程序：
bash 复制代码
```
go run writeMySQL.go
```

3.2 测试1：模拟主库故障（关闭初始主库）

操作：在184.155（初始主库maria-05）执行命令关闭MySQL：

bash 复制代码

/etc/init.d/mysql.server stop

观察结果：

数据写入程序：短暂中断（约10-20秒）后恢复正常，无数据丢失。
VIP迁移：在184.155、184.156、184.157执行ip a，发现VIP从184.155迁移到184.157（新主库）。
Orchestrator拓扑：在184.151执行orchestrator-client -c topology -i maria-05:3306，显示maria-05为unknown状态；执行orchestrator-client -c topology -i maria-06:3306，显示maria-07为新主库。

3.3 测试2：恢复旧主库并加入集群

目的：验证旧主库恢复后，如何手动加入集群（避免自动切换）。
操作：

重启184.155的MySQL：
bash 复制代码
```
/etc/init.d/mysql.server start
```

在184.155上配置主从关系（指向新主库184.157）：

sql 复制代码

STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO
  MASTER_HOST='192.168.184.157',
  MASTER_USER='repl',  # 复制账号
  MASTER_PASSWORD='Uid_dQc63',
  MASTER_AUTO_POSITION=1;  # GTID自动定位
START SLAVE;
-- 验证主从状态
SHOW SLAVE STATUS\G

验证：Orchestrator页面显示184.155已作为从库加入maria-07集群，恢复"一主两从"架构。

3.4 测试3：手动调整拓扑（页面操作）

目的：验证主动调整主库时，Hook是否正常触发VIP迁移。
操作：

登录Orchestrator页面，拖拽maria-06（从库）成为新主库。
观察结果：
- VIP迁移：执行ip a发现VIP从184.157迁移到184.156。
- 数据写入：Go程序短暂中断后恢复，无数据丢失。
恢复拓扑：将maria-05重新设为主库，在maria-06上执行START SLAVE恢复主从关系。

四、总结与生产建议

通过Orchestrator Hook，我们实现了MySQL故障转移时的VIP自动迁移，结合Go程序验证了集群的高可用性，核心优势如下：

自动化：故障后无需人工干预VIP，减少运维成本与操作失误。
高可用：数据写入仅短暂中断，满足生产环境对可用性的要求。
可扩展：Hook脚本可灵活扩展（如添加DNS更新、告警通知等逻辑）。

生产环境建议

参数配置：MasterFailoverDetachReplicaMasterHost务必设为true，避免旧主频繁抢占主库。
日志排查：Hook脚本与Orchestrator日志需定期归档，便于故障溯源。
定期测试：每月模拟1-2次主库故障，验证Hook与切换流程的稳定性。
脚本优化：可在Hook脚本中添加重试逻辑（如VIP操作失败时重试2-3次），提升鲁棒性。