引言
高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。一般而言，衡量高可用做到什么程度可以通过一年内服务不可用时间作为参考，要做到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工作原理
MHA工作原理如下：
-
从宕机崩溃的master保存二进制日志事件（binlog events）;
-
识别含有最新更新的slave；
-
应用差异的中继日志（relay log）到其他的slave；
-
应用从master保存的二进制日志事件（binlog events）；
-
提升一个slave为新的master；
-
使其他的slave连接新的master进行复制；
故障处理
1、MHA如何监控master和故障转移？
1.1 验证复制设置以及确认当前master状态
连接所有hosts，MHA自动来确认当前master是哪个，配置文件中无需指定哪个是master。
如果其中有任何一个slave挂了，脚本立即退出，停止监控。
如果有一些必要的脚本没有在MHA Node节点安装，那么MHA在这个阶段终止，且停止监控。
1.2 监控master
监控master，直到master挂了。
这个阶段，MHA不会监控slave，Stopping/Restarting/Adding/Removing操作在slave上，不会影响当前的MHA监控进程。当你添加或者删除slave的时候，请更新好配置文件，最好重启MHA。
1.3 检测master是否失败
如果MHA Manger三次间隔时间都没办法连接master server，就会进入这个阶段。
如果你设置了secondary_check_script ，那么MHA会调用脚本做二次检测来判断master是否是真的挂了。
接下来的步骤，就是masterha_master_switch的工作流程了。
1.4 再次验证slave的配置
如果发现任何不合法的复制配置（有些slave的master不是同一个），那么MHA会停止监控，且报错。可以设置ignore_fail忽略。
这一步是处于安全考虑，很有可能，复制的配置文件已经被改掉了，所以double check是比较推荐的做法。
检查最后一次failover（故障转移）的状态
如果上一次的failover报错，或者上一次的failover结束的太近（默认3天），MHA停止监控，停止failover，那么在masterha_manager命令中设置ignore_last_failover，wait_on_failover_error来改变这一检测。这么做，也是出于安全考虑。频繁的failover，检查下是否网络出问题，或者其他错误呢？
1.5 关掉失败的master的服务器（可选）
如果在配置文件中定义了master_ip_failover_script and/or shutdown_script ，MHA会调用这些的脚本。
关闭dead master，避免脑裂（值得商榷）。
1.6 恢复一台新master
从crashed master服务器上保存binlog到Manager（如果可以的话
如果dead master可以SSH的话，拷贝binary logs从最新的slave上的end_log_pos(Read_Master_Log_Pos)位置开始拷贝。
选举新master
一般根据配置文件的设置来决定选举谁，如果想设置一些候选master，设置candidate_master=1；如果想设置一些host，永远都不会选举，设置no_master=1；确认最新的slave （这台slave拥有最新的relay-log）。
恢复和提升新master
根据老master binlog生成差异日志，应用日志到new master，如果这一步发生错误（如：duplicate key error），MHA停止恢复，并且其余的slave也停止恢复。
2 MHA如何在线快速切换master？
下面的步骤，就是masterha_master_switch—master_state=alive做的事情。
2.1 验证复制设置以及确认当前master状态
连接配置文件中列出的所有hosts，MHA自动来确认当前master是哪个，配置文件中无需指定哪个是master。
执行 flush tables 命令在master上（可选）. 这样可以缩短FLUSH TABLES WITH READ LOCK的时间。
既不监控master，也不会failover。
检查下面的条件是否满足。
A. IO线程是否在所有slave上都是running。
B. SQL线程是否在所有slave上都是running。
C. Seconds_Behind_Master 是否低于2秒（—running_updates_limit=N）。
D. master上是否没有长的更新语句大于2秒。
2.2 确认新master
新master需要设置： –new_master_host参数。
原来的master和新的master必须要有同样的复制过滤条件（binlog-do-db and binlog-ignore-db）。
2.3 当前master停写
如果你在配置中定义了master_ip_online_change_script，MHA会调用它。可以通过设置SET GLOBAL read_only=1来完美的阻止写入。
在老master上执行FLUSH TABLES WITH READ LOCK来阻止所有的写（–skip_lock_all_tables可以忽略这一步）。
2.4 等待其他slave追上当前master，同步无延迟
调用这个函数MASTER_LOG_POS()。
2.5 确保新master可写
执行SHOW MASTER STATUS来确定新master的binary log文件名和position。
如果设置了master_ip_online_change_script，会调用它。可以创建写权限的用户，SET GLOBAL read_only=0。
2.6 让其他slave指向新master
并行执行CHANGE MASTER, START SLAVE。
故障处理
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流程图
MHA Server会间隔性检查对应MySQL集群的SSH状态和MySQL状态，发现异常，则执行切换。
而在58集团MySQL架构中，使用腾讯提供的TGW（LVS）作为负载均衡，故MHA不能很好的匹配现有MySQL结构。
因此，在WMHA中，对检测流程进行了修改，详情见下图：
MHA流程图
WMHA Server在监控SSH和MySQL状态的同时，加入了探测VIP的连通性的流程。同时，触发切换操作时，也会更新VIP信息。
具体的检测流程见下图，WMHA会优先探测VIP存活状态
检测流程
WMHA切换流程
在上述检测流程中，会优先监测VIP状态。在切换过程中，为防止误切，也加入了对VIP探活的流程。
具体流程如下：
-
获取配置文件信息；
-
校验配置文件与运行配置一致性；
-
执行SSH连通性检测；
-
再次检测主库状态；
-
检测VIP状态；
-
获取复制信息、延时信息；
-
应用差异日志；
-
追平数据后，执行切换；
WMHA切换流程
每一模块检测失败，均有对应的消息通知，后文会详述。
WMHA消息通知
原生的MHA中，消息通知由send_report脚本发送，但是消息类型单一，不能及时感知切换进度。
在WMHA中，丰富了消息通知。消息分类如下：
-
开始在线切换；
-
在线切换结果：成功/失败；
-
开始故障切换；
-
故障切换结果：成功/失败；
同时，支持短信、邮件通知，后续会支持内部IM通知。
image.png
image.png
WMHA目录结构
原生MHA中，通过conf目录下的不同配置文件来管理多套MySQL集群，状态文件、保存的binlog、切换结果等，都放在根目录下，不方便管理。
在WMHA中，采用每套MySQL集群一个目录的方式来部署。除状态文件（master_status.health）放置在每个实例的工作目录（manager_workdir）的根目录下之外，其余皆分别归类。
image
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的时间，去做更多有意义的事情。
网友评论