MySQL 高可用之MHA

前言

在 MySQL 的高可用方案中，MHA（Master High Availability）可谓是最为成熟、使用最为广泛的方案之一了。其作者 Yoshinori Matsunobu 现就职于 Facebook，该架构采用 perl 语言编写，可完成秒级别的主库故障切换，接下来详细介绍 MHA 在铜板街的上线之路。

架构选型

在开始计划实施 MySQL 数据库高可用时，我们选择了比较流行的几大方案，分别进行了调研。

MHA：适用于一主多从的架构体系，在故障切换过程中，可从宕机的主库上保存二进制日志，最大程度的保证数据不丢失。但是需要 MHA 架构内所有的节点都必须可以 ssh互通。

MMM：（Master-Master replication manager for MySQL） 适用于双主架构，是一套支持双主故障切换和日常管理的脚本程序，虽无需架构内 ssh 互通，但是无法保存主库的二进制日志，所以数据一致性不如 MHA 高。

PXC：（Percona XtraDB Cluster）是 percona 公司提供的一套高可用方案，需要三个或以上 percona 版本的 DB 节点，该架构保证了数据强一致，但是同等硬件配置下，性能不如 MHA 和 MMM，尤其木桶效应明显，该方案还需依赖外部组件。

MGR：（MySQL Group Replication）是 MySQL 官方发布的高可用架构，该方案依赖于 MySQL5.7 版本，适用于主从架构，但是需要类似主库全表包含主键等相关依赖，成熟度不如以上方案，该方案同样需要依赖外部组件。

综上，在结合自身的业务场景，最终选择 MHA 作为 MySQL 集群的高可用方案。以下详细介绍 MHA 的体系结构及部署和测试的各项细节。

架构简介

MHA由两个部分组成，如下图1：管理节点（以下称为 manager ）和数据节点（以下称为 node ）组成，其中 manager 可以单独部署也可以部署在 DB 节点上，为规范，我们将 manager 单独部署在一台机器上（为节省资源，可以部署在虚拟机上，并做好备份），node 部署在每个 DB 上和 manager 上。

MHA架构中，manager 会定时探测集群中的主库节点，一般为每秒钟探测一次，当主库出现故障后，拉取主库和最新从库的差异日志并应用到该从库上，将该从库提升为新的主库，然后把其他所有的从库重新指向新的主库，由于主库采取 VIP 方式对外提供服务，整个故障转移的过程对应用程序是完全透明的。

为最大程度的保证数据一致性，对于核心业务的数据库参数 sync_binlog、

innodb_flush_log_at_trx_commit 均设置为1，每次主库事物提交后，都立即写入 binlog 并且立即将缓存中的 redo 日志写到日志文件，并调用操作系统 fsync 刷新 IO 缓存。主从同步上采用半同步复制，主库的每个事物需要等待从库返回响应后再对外宣布成功，最大程度的保证数据的一致性（ MySQL的半同步复制即使在 5.7 版本中也没有做到数据的强一致）。

图 1

原理说明

由于篇幅有限，本章将着重介绍MHA的工作原理，以及相关实现的细节，具体的搭建步骤，将在下一章节重点介。

以下图 图2为例，总结一下MHA的工作原理（以下序列号和图2序列号一一对应）。

manager 确认主库宕机后，触发 master_ip_failover 脚本，摘除 VIP。

manager 识别最新的从库（同步主库数据最多的 slave1）binlog 的位置。

manager 把主库和最新从库的差异 binlog 保存到 manager 本地。

manager 将本地保存的差异 binlog 复制到最新从库上，并进行应用，应用完成后，将原主库的 VIP 设置到该从库上，提升该从库为新的主库。

将其他所有从库指向新的主库。

图 2

那么MHA具体是通过什么操作的呢，其实就是一些 perl 脚本，包括 manager 和 node 工具包，具体说明如下：

MHAmanager 端常用工具：

masterha_master_switch：控制故障转移（常用，一般手动在线切换主库使用）

masterha_check_ssh：检查 MHA 的 SSH 配置状况 （常用，每次配置完 ssh 互通需测试一下）

masterha_check_repl：检查 MySQL 复制状况 （常用，每次部署完 MHA 后，都需要进行检测）

masterha_manager：启动 MHA 使用（常用，主库自动故障切换时开启 MHA 所需命令）

masterha_secondary_check：对主库监听进行二次校验

masterha_check_status：检查当前 MHA 运行状态

masterha_master_monitor：监测 master 是否宕机

masterha_stop：停止 MHA

manager 使用到的脚本：

master_ip_failover_script=/usr/local/bin/master_ip_failover设置自动 failover 时候使用到的切换脚本

master_ip_online_change_script=/usr/local/bin/master_ip_online_change设置手动在线切换时所使用的切换脚本

report_script=/usr/local/bin/send_report 设置切换完发送通知使用的的脚本，仅自动故障切换场景时触发，手动在线切换时不触发该脚本

当MHA到主库 192.168.1.220 之间的网络出现问题时，再通过从库 192.168.1.221（该从库尽量不要选择备主）进行登录验证，两次验证都出现问题时，MHA 认为主库宕机。

MHA node 端常用工具（这些工具由 manager 触发，不需人工操作）：

save_binary_logs：保存和复制 master 的二进制日志

apply_diff_relay_logs：识别差异的中继日志事件，并将其差异的事件应用到其他从库

purge_relay_logs：MHA 在切换过程中，可能依赖从库的 relay log，利用该脚本采用定期清除 relay log 的方式，防止其自动清除（该脚本需要手工在从库上进行部署，具体部署方法后面文章详细说明），该脚本在从库上需要有数据库的 SELECT, RELOAD, SUPER 权限才可以执行。

部分细节说明

软件下载地址：

强烈建议使用MHA作者的git地址下载0.56版本的tarball，其git地址：

https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads，

其他地址如 Google code中的软件包，笔者经过测试，都会有bug，Google code地址：

https://code.google.com/p/mysql-master-ha/downloads/list，可自行测试。

VIP是通过脚本方式实现，分别配置在 master_ip_failover 和 master_ip_online_change中，核心代码为：

以此方式下掉原故障主库VIP，在新的主库上添加VIP。

本次 MHA 架构使用 VIP，多数公司使用域名方式连接 DB，可通过修改域名解析到VIP，重启应用，即可快速完成 MHA 架构的上线。

授权相关说明。由于从库在本地应用差异的 relay log 时，需要对所有 DB 有 all 权限，所以 MHA 的授权时，防止权限外泄，要指定所有节点（manager 和 node）的具体 IP 地址。

本章只介绍了 MHA 理论相关的方面，如有不当之处还望留言多多指教。下一次会将全部代码贴出来，可以直接使用进行搭建 MHA 。

参照：

1.《深入浅出MySQL 数据库开发、优化与管理维护（第二版）》