MySQL

MySQL MHA 完整详解

·14 分钟阅读·5532 字
MySQL原理高阶八股
📋 目录

MySQL MHA 完整详解

核心概念 MHA 是基于 MySQL 原生主从复制的自动故障转移高可用工具，主库故障 10~30 秒完成自动切换。

1. MHA 基础概述

1.1. 定义

MHA（Master High Availability Manager and Tools for MySQL），由日本工程师 Yoshinori Matsunobu 用 Perl 开发，是一套基于 MySQL 原生主从复制的自动故障转移高可用工具，专门解决单机主库宕机后，自动选从升主、重构复制拓扑的问题。
核心目标：

  1. 主库故障 10~30秒 完成自动切换，RTO极低；
  2. 切换过程最大限度补齐差异日志，保证多从库数据一致；
  3. 无侵入修改 MySQL 内核，兼容原生异步/半同步复制、GTID；
  4. 一套 Manager 可同时管理多套独立一主多从集群。

1.2. 两大核心组件

1.2.1. （1）MHA Node（数据节点，所有MySQL机器必须安装）

部署在每一台主、从MySQL实例上，是执行底层操作的代理工具，核心能力：

  1. 解析本地 binlog / relay log，对比复制位点；
  2. 故障时通过 SSH 抢救宕机主库残留 binlog；
  3. 对从库应用差异中继日志，统一数据位点；
  4. 执行 CHANGE MASTER TO、开关 read_only、启停复制线程；
  5. 提供全套操作命令集：save_binary_logs、apply_diff_relay_logs 等。

1.2.2. （2）MHA Manager（管理调度节点，集群大脑）

独立部署（推荐单独机器，不跑MySQL），负责监控、决策、调度整套切换流程：

  1. 定时心跳探测主库存活（SQL ping + 端口检测 + SSH连通性三重检测）；
  2. 判定主库客观故障后，协调所有 Node 执行数据补齐；
  3. 按规则选举最优从库晋升新主；
  4. 调用自定义脚本完成 VIP 漂移、告警、业务回调；
  5. 切换完成后重构所有从库复制关系，指向新主。

1.3. 生产标准架构（最小高可用）

1主2从 + 独立Manager，共4台机器：

  • Master：写节点，产生binlog；
  • Slave1：候选主 candidate_master=1；
  • Slave2：普通从库；
  • MHA Manager：独立监控调度节点。

禁止1主1从两节点架构：网络分区易发生脑裂，无备选从库兜底。

2. 前置MySQL基础环境要求（MHA运行必备）

2.1. 主从复制基础配置（my.cnf）

所有节点唯一 server-id，开启binlog、relay-log：

[mysqld]
server-id=1 # 主库；从库分别2、3
log_bin=/data/mysql/binlog/mysql-bin
binlog_format=ROW
relay_log=/data/mysql/relaylog/relay-bin
log_slave_updates=1 # 链式复制必备，从库记录binlog供其他从同步
expire_logs_days=7  # 定时清理binlog，防止磁盘打满
read_only=1         # 主库切换时MHA自动设为0

2.2. 账号权限

两套账号（所有节点统一账号密码）：

  1. 管理账号：Manager/Node 登录MySQL，需 REPLICATION SLAVE, RELOAD, SUPER 权限；
  2. 复制账号：repl，主从同步专用。

2.3. 免密SSH互通

所有MySQL节点、Manager之间 root 免密ssh，MHA远程拉取binlog、执行指令依赖SSH，SSH不通切换直接失败。

2.4. 推荐开启半同步复制（semi-sync）

异步复制存在数据丢失风险，半同步保证至少一个从库收到binlog后主库才返回写入成功，大幅降低切换丢数据概率。

2.5. GTID 模式（MHA 0.58+支持，强烈推荐）

GTID 无需手动指定binlog文件名和位点，自动匹配复制起点，简化切换后复制重构。

3. MHA Manager 完整监控机制

3.1. 三重故障探测（避免误切换）

默认 ping_interval=1 每秒探测一次，连续3次失败判定主观故障：

  1. SQL Ping：select 1 连接MySQL 3306，验证服务正常；
  2. 端口探测：检测3306端口是否存活；
  3. SSH连通性探测：判断机器硬件/网络是否完全宕机。

3.2. 两种故障区分，处理逻辑完全不同

  1. 可SSH连通，MySQL进程崩溃（实例故障）
    Node 通过SSH登录宕机主，拷贝本地未同步到从库的binlog，补齐到新主，最大程度不丢数据；
  2. 完全宕机/网络隔离（机器故障，SSH不通）
    无法抢救主库残留binlog，只能依靠现有从库已同步的relay log选举新主，存在少量数据丢失风险。

4. 全自动故障切换完整7大核心流程（重中之重）

4.1. Phase1：故障确认阶段

  1. Manager 多次ping主库失败，标记主库主观下线；
  2. 并行检测所有从库SSH、复制状态，确认主库客观故障，正式触发failover切换；
  3. 执行自定义故障前置告警脚本（短信/钉钉通知）。

4.2. Phase2：抢救宕机主库binlog（仅SSH可达时执行）

调用 save_binary_logs，通过Node拉取主库未同步的binlog，存到Manager临时目录，用于后续补齐从库差异数据。

4.3. Phase3：统一所有从库数据位点（消除从库间数据差异）

  1. 收集所有Slave Exec_Master_Log_Pos，找出relay log执行最完整的节点；
  2. 调用 apply_diff_relay_logs，将数据更完整从库的差异relay log同步到其他落后从库；
  3. 全部从库位点对齐，保证切换后所有从库数据完全一致。

4.4. Phase4：选举新Master（候选主选择规则，优先级从上到下）

  1. 配置 candidate_master=1 标记的从库优先；
  2. 排除 no_master=1 禁止升主的节点；
  3. 选择relay log执行位点最新、复制延迟最小的从库；
  4. 数据相同则按配置文件节点顺序。

4.5. Phase5：新主应用抢救的主库binlog

将Phase2抢救的宕机主binlog完整回放至新主，补齐宕机瞬间未同步数据；
新主执行 SET GLOBAL read_only=0，开启写入权限，正式对外提供写服务。

4.6. Phase6：重构所有剩余从库复制拓扑

  1. 并行对所有旧从库执行 CHANGE MASTER TO，指向新Master；
  2. 启动IO/SQL复制线程，同步新主binlog；
  3. 所有从库自动设为 read_only=1。

4.7. Phase7：VIP漂移与后置回调

  1. 执行 master_ip_failover_script 自定义脚本：VIP绑定到新主（Keepalived/云HaVip）；
  2. 执行告警、日志记录、业务切换回调脚本；
  3. 切换流程结束，Manager进程自动退出（防止重复切换，需人工修复旧主后重启MHA）。

5. 核心配套脚本（生产必须自定义）

MHA 本身不管理VIP、不发告警，依靠外部脚本扩展能力，配置文件三大核心脚本：

  1. master_ip_failover_script：自动故障切换时VIP漂移脚本（Keepalived、阿里云HaVip等）；
  2. master_ip_online_change_script：手动在线主从切换（无故障停机维护）时VIP切换；
  3. report_script：切换成功/失败告警通知脚本（企业微信、短信）。

5.1. VIP高可用配套方案

  1. 自建IDC：MHA脚本配合 Keepalived VRRP VIP，双层保障；
  2. 公有云：调用厂商API绑定HaVip弹性内网IP。

6. MHA 常用管理命令（Manager节点执行）

# 1. 检查所有节点SSH免密互通
masterha_check_ssh --conf=/etc/masterha/app1.cnf

# 2. 检查主从复制链路完整性
masterha_check_repl --conf=/etc/masterha/app1.cnf

# 3. 后台启动MHA监控管理进程
nohup masterha_manager --conf=/etc/masterha/app1.cnf &

# 4. 查看MHA运行状态
masterha_check_status --conf=/etc/masterha/app1.cnf

# 5. 手动在线切换主库（业务维护，无宕机）
masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive

# 6. 手动强制故障切换（主已彻底宕机）
masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=dead

7. MHA 优缺点分析

7.1. 优点

  1. 轻量无侵入，基于原生主从复制，无需改造MySQL；
  2. 切换速度快，10~30秒完成，适合对停机时间敏感业务；
  3. 自动补齐多从库差异日志，切换后所有从库数据统一；
  4. 支持GTID、半同步、链式复制，兼容5.7/8.0主流版本；
  5. 一套Manager管理多套集群，运维成本低；
  6. 可自定义VIP、告警、业务回调，扩展性强。

7.2. 缺点（生产高频踩坑点）

  1. Manager单点故障：原生单Manager，Manager宕机后集群失去监控，无法自动切换；
    解决方案：部署两套Manager双监控，或结合第三方监控检测Manager状态；
  2. 网络分区脑裂风险：两节点架构、SSH/MySQL端口分区可能出现双主抢写；
    规避：至少1主2从三节点架构；切换时关闭旧主写入权限；
  3. 异步复制存在丢数据可能：主库完全宕机无法抢救binlog；
    规避：强制开启半同步复制；
  4. 切换完成后MHA Manager进程自动退出，旧主修复上线后需人工重启MHA；
  5. 依赖SSH，SSH故障直接阻断切换流程；
  6. 仅支持一主多从架构，不支持分片分布式集群（对比MySQL Cluster、PXC）；
  7. 无内置负载均衡，必须配合VIP/中间件实现统一访问入口。

8. MHA vs PXC 主流MySQL高可用方案对比

维度MHA（主从复制）PXC（Galera多写集群）
底层原理原生异步/半同步主从复制Galera同步多节点复制，多写
节点写入仅单主可写，从只读所有节点同时支持写入
数据一致性半同步降低丢失概率，极端场景丢少量数据强同步，无事务丢失
切换速度10~30秒自动切换节点故障秒级剔除，无需升主流程
性能损耗几乎无额外损耗，原生复制性能同步复制有性能开销，高写入压力吞吐量下降
适用场景中小读写分离业务、传统主从架构强一致性金融业务、多活写入场景
扩容成本新增从库无需停机同步新增节点全量同步整库数据，大库慢

9. 生产最佳实践与避坑规范

9.1. 架构规范

  1. 最低三节点：1主2从，禁止1主1从；
  2. Manager独立部署，不和MySQL共用机器；
  3. 每个分片至少一个 candidate_master=1 候选从库；
  4. 所有机器跨机柜部署，避免单机柜断电整体失效。

9.2. 数据安全规范

  1. 强制开启半同步复制，主库等待至少一个从库ack；
  2. 开启GTID模式，简化复制重构；
  3. binlog至少保留7天，故障抢救日志有兜底；
  4. 主库磁盘充足，避免binlog磁盘打满导致服务宕机。

9.3. 网络与权限规范

  1. 所有节点SSH root免密互通，定期巡检SSH连通性；
  2. 防火墙放行3306、22端口，禁止节点间网络隔离；
  3. MySQL管理账号最小权限，禁止使用全权限root暴露外网。

9.4. 高可用配套

  1. MHA脚本结合Keepalived实现VIP漂移，双层高可用；
  2. 搭建监控告警：MHA进程存活、主从复制延迟、binlog磁盘、切换事件全告警；
  3. 定期演练故障切换：手动停主库模拟宕机，验证切换、VIP、告警全流程。

9.5. 切换后运维规范

  1. 原故障主库修复后，重置复制，作为新主的从库接入集群；
  2. 手动重启MHA Manager监控进程；
  3. 核对所有从库复制状态、数据一致性。

10. 面试核心速记总结

  1. MHA 分 Manager（调度监控）+ Node（每台MySQL执行代理）两大组件；
  2. 基于MySQL原生主从复制，自动故障切换10~30秒，核心是补齐从库relay log统一数据位点；
  3. 切换核心步骤：故障检测→抢救主binlog→统一从库日志→选举新主→重构复制→VIP漂移；
  4. 选举新主优先级：candidate候选标记 > 数据最新无延迟从库；
  5. 原生Manager单点，需独立部署，切换完成进程自动退出；
  6. 生产标配：1主2从架构、半同步复制、GTID、Keepalived VIP、SSH免密；
  7. 短板：单主写入、Manager单点、异步复制存在极小丢数据风险；适合读写分离传统MySQL业务。

关联文档

返回首页订阅更新