引言
高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。一般而言，衡量高可用做到什么程度可以通过一年内服务不可用时间作为参考，要做到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：启动MHA
- masterha_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：识别差异的中继日志事件并将其差异的事件应用于其他的slave
- filter_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的时间，去做更多有意义的事情。
