在 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序列号一一对应)。

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

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

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

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

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

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

1secondary_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 权限才可以执行。

部分细节说明

软件下载地址:

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

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

-master-ha/downloads/list,可自行测试。

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

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

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

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

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

作者简介

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