​引言

高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。一般而言，衡量高可用做到什么程度可以通过一年内服务不可用时间作为参考，要做到3个9的可用性，一年内只能累计有8个小时不可服务，而如果要做到5个9的可用性，则一年内只能累计5分钟服务中断。

对于一个系统而言，可能包含很多模块，比如前端应用，缓存，数据库，搜索，消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用可能更复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此数据库的高可用方案，一般会同时考虑方案中数据一致性问题。

项目背景

原MySQL高可用方案，是58集团自研的，可以满足基本的存活检测、故障切换等日常运维需求。但是存在一些缺陷：

故障切换时，直接切换，不会追补数据；基于配置文件进行单进程扫描，效率差，且缺少周边工具；不能在线切换；仅从监控机探测主库服务状态，检测指标单一，有误切风险；

随着MySQL集群数量增长，上述缺陷所带来的问题日益严重，因此决定采用新的MySQL高可用方案。

高可用方案WMHA

为解决上面提到的问题，同时尽可能低成本改造现有MySQL架构，经多次讨论，决定采用业内比较成熟的MHA方案，并在此方案的基础上，进行改造，原因如下：

沉淀多年，相对成熟；无需调整现有MySQL架构；Perl开发，完全开源，方便改造；

由于原生MHA不能完全适用于集团现有MySQL架构，所以对部分功能进行了改造，支持对LVS VIP的检测、支持切换队列等功能，改造后的方案命名为WMHA。

MHA简介

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。

在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

MHA工作原理

MHA工作原 理如下：

从宕机崩溃的master保存二进制日志事件（binlog events）;识别含有最新更新的slave；应用差异的中继日志（relay log）到其他的slave；应用从master保存的二进制日志事件（binlog events）；提升一个slave为新的master；使其他的slave连接新的master进行复制；

MHA软件由两部分组成，Manager工具包和Node工具包，具体的说明如下。

MHA工具介绍

Manager工具包主要包括以下几个工具：

masterha_check_ssh：检查MHA的SSH配置状况masterha_check_repl：检查MySQL复制状况masterha_manger：启动MHAmasterha_check_status：检测当前MHA运行状态masterha_master_monitor：检测master是否宕机masterha_master_switch：控制故障转移（自动或者手动）masterha_conf_host：添加或删除配置的server信息

Node工具包（这些工具通常由MHA Manager的脚本触发，无需人为操作）主要包括以下几个工具：

save_binary_logs：保存和复制master的二进制日志apply_diff_relay_logs：识别差异的中继日志事件并将其差异的事件应用于其他的slavefilter_mysqlbinlog：去除不必要的ROLLBACK事件（MHA已不再使用这个工具）purge_relay_logs：清除中继日志（不会阻塞SQL线程）

MHA相关脚本

MHA Manager：

masterha_check_ssh：检查mha的ssh配置情况；masterha_check_repl：检查MySQL复制情况；masterha_manager：启动mha；masterha_check_status：检查当前mha运行状态；masterha_master_monitor：检测master是否宕机；masterha_check_switch：控制故障转移（自动或手动）；masteha_conf_host：添加或删除配置的server信息；

MHA Node：

save_binary_logs：保存和复制master的二进制文件；apply_diff_relay_logs：识别差异的relay log并将其差异event应用于其他slave；filter_mysqlbinlog：去除不必要的rollback event；purge_relay_logs：清除relay log；

WMHA原理

WMHA检测流程

MHA流程图如下：

MHA Server会间隔性检查对应MySQL集群的SSH状态和MySQL状态，发现异常，则执行切换。

而在58集团MySQL架构中，使用腾讯提供的TGW（LVS）作为负载均衡，故MHA不能很好的匹配现有MySQL结构。

因此，在WMHA中，对检测流程进行了修改，详情见下图：

WMHA Server在监控SSH和MySQL状态的同时，加入了探测VIP的连通性的流程。同时，触发切换操作时，也会更新VIP信息。

具体的检测流程见下图，WMHA会优先探测VIP存活状态

WMHA切换流程

在上述检测流程中，会优先监测VIP状态。在切换过程中，为防止误切，也加入了对VIP探活的流程。

具体流程如下：

获取配置文件信息；校验配置文件与运行配置一致性；执行SSH连通性检测；再次检测主库状态；检测VIP状态；获取复制信息、延时信息；应用差异日志；追平数据后，执行切换；

每一模块检测失败，均有对应的消息通知，后文会详述。

WMHA消息通知

原生的MHA中，消息通知由send_report脚本发送，但是消息类型单一，不能及时感知切换进度。

在WMHA中，丰富了消息通知。消息分类如下：

开始在线切换；在线切换结果：成功/失败；开始故障切换；故障切换结果：成功/失败；

同时，支持短信、邮件通知，后续会支持内部IM通知。

WMHA目录结构

原生MHA中，通过conf目录下的不同配置文件来管理多套MySQL集群，状态文件、保存的binlog、切换结果等，都放在根目录下，不方便管理。

在WMHA中，采用每套MySQL集群一个目录的方式来部署。除状态文件（master_status.health）放置在每个实例的工作目录（manager_workdir）的根目录下之外，其余皆分别归类。

WMHA切换队列

现阶段的WMHA未实现各网段、多节点探测，存在由于网络质量导致大规模切换的风险。为防止出现该情况，WMHA中增加了Maximum_queue_length参数。该参数以WMHA Server为基准，限制同一时间切换的数量。

如果同一台服务器，在短时间内切换请求达到该阈值，则会放弃后续切换，日志中记录类似“Too many failover...”的信息。

后续计划

WMHA作为MySQL高可用的核心组件，自身的单点问题也应被重视。使用Etcd构造WMHA的高可用集群是一个不错的方案。

作为由MHA改造的项目，监测指标仍然依赖于网络连通性。网络质量不好，会对WMHA造成很严重的影响。所以，可在各个网段部署哨兵，做为WMHA触发切换的一个必要条件，规避因网络质量问题而导致的大批量切换的风险。

结语

MHA作为业界成熟的高可用方案，被广泛使用。但MHA是keepalive时代的产物，已不太适用于当下环境。面对以指数级增长的数据量和各种复杂数据库架构，人工干预的运维方式正逐渐落伍。WMHA在MHA的基础上，通过增加其自身健壮性，逐步减少DBA参与，在保证数据库服务可用性的同时，尽可能的释放DBA的时间，去做更多有意义的事情。

欢迎大家关注“58架构师”微信公众号，定期分享云计算、AI、区块链、大数据、搜索、推荐、存储、中间件、移动、前端、运维等方面的前沿技术和实践经验。