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 版本中也没有作到数据的强一致）。

原理说明

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

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

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

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

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

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

5. 将其余全部从库指向新的主库。

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

MHA manager 端经常使用工具：

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 设置切换完发送通知使用的的脚本，仅自动故障切换场景时触发，手动在线切换时不触发该脚本

1 secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.1.221 --user=root --master_ip=192.168.1.220复制代码

当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 权限才能够执行。

部分细节说明

1. 软件下载地址：

   强烈建议使用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，可自行测试。

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

1 1ip addr add 192.168.1.220/32 dev eth0;arping -q -c 2 -U -I eth0 192.168.1.220
2 1ip addr del 192.168.1.220/32 dev eth0
复制代码

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

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

4. 受权相关说明。因为从库在本地应用差别的 relay log 时，须要对全部 DB 有 all 权限，因此 MHA 的受权时，防止权限外泄，要指定全部节点（manager 和 node）的具体 IP 地址。

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

参照：

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

做者简介

天元，铜板街DBA，2017 年 7 月加入团队，目前主要负责公司全部业务的数据库相关运维。

                            

                    更多精彩内容，请扫码关注 “铜板街科技” 微信公众号。