MHA整体工作流程
  1. Manager 执行masterha_check_ssh、masterha_check_repl前置校验；
  2. 启动masterha_manager，后台masterha_master_monitor持续探活 Master；
  3. Master 宕机，Monitor 判定故障，调用masterha_master_switch启动切换；
  4. SSH 远程调用旧 Master Node 的save_binary_logs抢救 binlog；
  5. 在各 Slave 执行apply_diff_relay_logs比对 relaylog，选出数据最新从库升主；
  6. 其余从库重新指向新主，执行purge_relay_logs清理冗余中继日志；
  7. 切换完成，可用masterha_check_status查看集群新状态。

MHA（MHA Manager + MHA Node）全套组件详细解析

一、MHA Manager 管理组件（核心调度大脑）

核心定位

运行在独立服务器（不建议放数据库节点），全程监控主从集群状态、判断主库宕机、自动触发故障转移、选新主、重构主从，所有带*的是 MHA 后台常驻 / 故障切换核心脚本。

1. masterha_manger

  • 作用：MHA 管理程序入口，启动 MHA 监控进程
  • 用法示例：
nohup masterha_manager --conf=/etc/mha/app1.cnf &
  • 运行后后台持续轮询检测 Master 健康状态；一旦主库故障，自动执行故障转移，转移完成后该进程会自动退出（如需持续监控需要搭配监控脚本重启）。
  • 配套查看运行状态命令：masterha_check_status

2. masterha_check_ssh

  • 作用：检查 Manager 节点与所有 MySQL 节点、MySQL 节点之间免密 SSH 互通是否正常
  • MHA 大量远程执行脚本、拷贝 binlog、远程启停数据库都依赖 SSH，不通直接无法启动集群。
  • 执行命令：masterha_check_ssh --conf=/etc/mha/app1.cnf

3. masterha_check_repl

  • 作用：校验 MySQL 主从复制链路完整性，是集群上线前必做检查
  1. MHA 既支持传统文件位置复制，也支持 GTID 复制，现在生产环境强制 GTID；
  2. 脚本会检测：主从 IO/SQL 线程是否正常、复制延迟、是否有复制报错、GTID 是否一致、是否存在只读冲突等；
  3. 校验失败 MHA 拒绝启动，避免故障切换后数据不一致。
  • 执行命令：masterha_check_repl --conf=/etc/mha/app1.cnf

4. masterha_master_monitor（* 核心监控脚本）

  • 后台常驻脚本，由masterha_manager调用，核心职责：
  1. 周期性通过端口探测、MySQL 连接探测判断 Master 存活；
  2. 区分主库网络不通、MySQL 进程崩溃、服务器宕机三种场景；
  3. 多次重试确认非临时抖动后，判定 Master 故障，触发后续切换流程。

5. masterha_check_status（* 集群状态查询）

  • 日常运维最常用命令
  • 功能：读取 MHA 配置文件，输出当前集群角色：谁是 Master、谁是候选 Slave、MHA manager 进程是否在运行、上次切换日志位置。
masterha_check_status --conf=/etc/mha/app1.cnf

6. masterha_master_switch（* 故障切换核心）

MHA 手动 / 自动切换的执行器，分为两种模式：

  1. 自动故障转移：Manager 检测宕机后自动调用，无需人工干预；
  2. 手动切换（主库正常在线切换，计划性迁移）：运维主动执行，用于版本升级、硬件维护。

执行示例：

# 手动在线切换主库
masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=新主IP
# 手动强制故障切换（主库确实宕机）
masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=dead

内部动作：选最优从库提升为新主、其他从库重新指向新主、补全缺失 binlog、更新 VIP（需自定义脚本）。

7. masterha_conf_host（* 集群节点动态管理）

  • 无需修改配置文件重启 MHA，在线增删 MySQL 集群节点；
  • 场景：集群扩容新增从库、下线故障节点、修改节点权重。

二、MHA Node 节点组件（所有 MySQL 实例必须安装）

核心定位

部署在每一台 MySQL 服务器（原 Master、所有 Slave），不独立运行守护进程，全部由 Manager 通过 SSH 远程调用执行，负责日志抢救、数据补全、清理中继日志，保证故障切换数据零丢失。

1. save_binary_logs 抢救二进制日志（最关键）

解决痛点：Master 宕机瞬间，已经写入内存 binlog 但未刷入磁盘，从库还没拉取到，直接切换会丢数据。

执行逻辑：

  1. Manager 判定 Master 宕机后，尝试通过 SSH 连接旧 Master；
  2. Node 组件save_binary_logs拷贝旧 Master 磁盘上残留的 binlog 文件；
  3. 把缺失的 binlog 事件差异部分，传输到候选新主；
  4. 在新主回放，保证所有已提交事务全部落地，实现数据一致性。

如果旧主机彻底断电无法 SSH 连接，该步骤无法执行，只能依赖已有从库已同步的数据。

2. apply_diff_relay_logs 应用差异中继日志

作用：统一所有从库数据位点

  1. 故障时各个 Slave 的 relay log（中继日志）回放进度不一致；
  2. 该脚本对比各个从库已执行的 GTID / 日志位点，找出未执行的差异 relay log 事件；
  3. 在待提升为主库的节点完整回放所有中继日志，确保这个候选节点数据是集群中最新的；
  4. 后续其他从库以它为新主，建立复制关系。

简单理解：选出数据最全的从库当新 Master。

3. purge_relay_logs 清理中继日志

作用：安全自动删除 MySQL 中继日志

  1. 不会粗暴直接删除文件，先判断 SQL 线程是否已经回放完毕 relay log；
  2. 只删除已经完整应用完毕的中继日志，绝不中断 SQL 复制线程；
  3. 日常定时调用或切换后调用，防止磁盘被大量 relaylog 占满；
  4. 替代手动PURGE RELAY LOGSSQL 语句，更安全。
上一篇
下一篇