MHA架构详解

MHA基本概念

MHA（Master High Availability）是一套成熟的MySQL高可用解决方案，由日本DeNA公司的Yoshinori Matsunobu开发。它主要用于实现MySQL主从架构下的自动化故障转移和主从切换功能。

核心功能特性

  1. 快速故障转移：

    • 能够在30秒内自动完成主库故障检测和从库提升
    • 典型的故障转移时间在10-30秒之间
    • 支持手动触发的主库切换（计划内切换），通常仅需0.5-2秒

  2. 数据一致性保障：

    • 通过对比各从库的relay log差异，确保数据一致性
    • 支持自动从旧主库获取binlog进行数据修复

  3. 灵活的部署方式：

    • 支持标准的主从复制架构
    • 兼容基于GTID的复制模式

典型应用场景

  1. 金融交易系统：需要保证交易数据零丢失的支付系统
  2. 电商平台：大促时段的订单处理系统、商品库存管理系统
  3. 社交网络服务：用户关系链存储系统、即时消息存储系统

工作原理

  1. 监控阶段：MHA Manager通过定期ping检查主库可用性
  2. 故障检测：当主库不可达时，启动二次确认机制
  3. 故障转移流程：识别数据最接近主库的候选从库，应用差异relay log确保数据一致

组成部分

1. MHA Manager（管理节点）

MHA Manager是整个架构的控制中心，负责监控和管理整个MySQL主从复制集群。

  • 部署方式灵活：可以独立部署在专用管理服务器上，也可以部署在某台Slave节点上

  • 主要职责：

    • 持续监控Master节点的健康状态
    • 在Master故障时自动触发并控制故障转移流程
    • 实时检查MySQL复制状态和延迟情况

  • 典型工作流程：

    1. 每3秒（可配置）检测一次Master可达性
    2. 当连续3次检测失败时判定Master故障
    3. 自动选择数据最新的Slave作为新Master

2. MHA Node（数据节点）

MHA Node是运行在每个MySQL实例上的代理程序。

  • 核心功能：
    • 在Master节点上：实时保存和传输二进制日志(binlog)
    • 在Slave节点上：接收并应用中继日志(relay log)
    • 精确识别各Slave间的日志差异点
    • 将缺失的日志事件应用到落后的Slave

故障处理

MHA故障处理机制详解

  1. 保存宕机主库的二进制日志

    • 自动检测到Master宕机后，立即将Master服务器的binlog日志文件完整保存
    • 通过SSH连接到原Master服务器，将未同步的binlog传输到管理节点

  2. 定位最新的从库

    • 通过对比所有Slave的SHOW SLAVE STATUS信息
    • 根据Exec_Master_Log_Pos和Relay_Log_Pos确定数据最接近Master的Slave

  3. 修复其他从库

    • 从最新Slave获取relay log信息
    • 使用mysqlbinlog工具解析和重放relay log到其他落后Slave

  4. 主从切换操作

    • 在最新Slave执行STOP SLAVE; RESET MASTER;
    • 修改my.cnf配置，启用log-bin等主库必需参数
    • 通过CHANGE MASTER TO命令提升为新的Master

  5. 重建复制拓扑

    STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='new_master_ip';
START SLAVE;

主备切换

主备切换是指将备库转换为主库，原主库转换为备库的过程。

主备切换策略

  1. 可靠性优先策略：确保数据一致性为最高优先级

    • 典型实现步骤： a) 停止主库写入 b) 等待备库追上主库（Seconds_Behind_Master=0） c) 提升备库为新主库 d) 开启新主库写入
    • 适用场景：金融交易、订单系统等对数据一致性要求严格的业务

  2. 可用性优先策略：保证服务可用性为最高优先级

    • 典型实现步骤： a) 直接提升备库为新主库 b) 允许新主库立即接受写入 c) 原主库追赶数据
    • 适用场景：社交网络、内容平台等更注重服务连续性的业务

主备延迟

主备延迟是由主从数据库同步延迟导致的性能指标。

关键时间点：

  1. T1时刻：主库A完成事务执行并写入binlog文件
  2. T2时刻：备库B完全接收到该binlog
  3. T3时刻：备库B执行完该binlog中的事务

主备延迟计算公式：延迟时间 = T3 - T1

重要字段：

  • Seconds_Behind_Master：表示当前备库延迟秒数
  • Relay_Log_Pos：备库当前执行的binlog位置
  • Master_Log_File：备库正在读取的主库binlog文件

延迟原因

  1. 备库机器性能问题

    • 硬件配置不足
    • 资源过载：一台机器同时作为多个主库的备库
    • 网络瓶颈

  2. 分工问题

    • 读操作负载：备库承担了应用的大量读请求
    • 后台任务干扰

  3. 大事务操作

    • 单次删除大量数据
    • 大表结构变更（如为千万级表添加索引）
    • 批量导入数据

可靠性优先 vs 可用性优先

可靠性优先流程：

  • 判断从库B的 seconds_behind_master 值
  • 把主库A改为只读状态（readonly=true）
  • 等待从库B的 seconds_behind_master 值降为0
  • 把从库B改为可读状态（readonly=false）
  • 把业务请求切换至从库B

可用性优先：

  • 不等主从同步完成，直接把业务请求切换至从库B
  • 几乎不存在不可用时间，但会使数据不一致

多数情况下，优先选择可靠性优先战略，在满足数据可靠性的前提下，MySQL的可用性依赖于同步延时的大小，同步延时越小，可靠性就越高。

总结

MHA作为MySQL高可用解决方案的核心优势：

  1. 自动故障转移速度快：10-30秒内自动完成
  2. 数据一致性保障：自动识别和应用最新binlog事件
  3. 性能表现优异：支持多种复制模式
  4. 集中式监控管理：可管理多个MySQL集群

局限性：

  • 需要至少一个从库才能工作
  • 故障转移期间会有短暂的写入中断
  • 需要额外的Manager节点进行监控管理

目前MHA主要支持一主多从架构，要搭建MHA，要求一个复制集群中必须最少有三台数据库服务器。

更新丢失问题

  • 异步复制导致更新覆盖

MMM架构

基本介绍

MMM（Master-Master Replication Manager for MySQL）是一套开源的MySQL高可用解决方案。

核心功能

  1. 监控MySQL主从复制状态
  2. 自动检测节点故障并进行故障转移
  3. 管理虚拟IP地址实现客户端透明切换

节点角色

  • Writer节点：负责处理所有的写操作
  • Reader节点：负责处理读请求

故障处理流程

  1. VIP移除
  2. 角色切换
  3. 拓扑重构

监控机制

Monitor监控服务器

  • 实时收集各节点健康状态指标
  • 通过心跳检测判断节点故障

Agent代理程序

  • 运行在每个MySQL服务器上
  • 监控本地MySQL服务状态
  • 执行Monitor下发的管理指令