实验环境

此次实验的环境如下

• MySQL 5.7.25

• Redhat 6.10

• 操作系统账号:mysql

• 数据库复制账号:repl

• 复制格式:基于行的复制

• MHA版本: 0.57

1. MHA简介

关于简介我这里就摘取下网上的说法

MHA（Master High Availability）是一套相对成熟的MySQL高可用方案，能做到在0~30s内自动完成数据库的故障切换操作，在master服务器不宕机的情况下，基本能保证数据的一致性。

他由两部分组成

• MHA Manager（管理节点）

• MHA Node（数据节点）

MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave上。

MHA Node则运行在每个mysql节点上

MHA Manager会定时探测集群中的master节点，当master出现故障时，它自动将最新数据的slave提升为master，然后将其它所有的slave指向新的master。

在MHA自动故障切换过程中，MHA试图保存master的二进制日志，从而最大程度地保证数据不丢失

但这并不总是可行的，譬如，主服务器硬件故障或无法通过ssh访问，MHA就没法保存二进制日志，这样就只进行了故障转移但丢失了最新数据

可结合MySQL 5.5中推出的半同步复制来降低数据丢失的风险。

2. 各组件介绍

上面提到MHA由Manager工具包和Node工具包组成，其中Node软件安装在mysql节点中，manager安装在管理节点中，也可安装在其中一个mysql节点

在安装完组件时会各自生成一些脚本，下面来介绍(具体的安装我们下节介绍)

MHA Manager：

1. masterha_check_ssh：检查MHA的SSH配置状况

2. masterha_check_repl：检查MySQL的复制状况

3. masterha_manager：启动MHA

4. masterha_check_status：检测当前MHA运行状态

5. masterha_master_monitor：检测master是否宕机

6. masterha_master_switch：控制故障转移（自动或手动）

7. masterha_conf_host：添加或删除配置的server信息

8. masterha_stop：关闭MHA

9. masterha_secondary_check:当MHA manager检测到master不可用时，通过该脚本来进一步确认，减低误切的风险。

MHA Node:

1. save_binary_logs：保存或复制master的二进制日志

2. apply_diff_relay_logs：识别差异的relay log并将差异的event应用到其它slave中

3. filter_mysqlbinlog：去除不必要的ROLLBACK事件（MHA已不再使用这个工具）

4. purge_relay_logs：消除中继日志（不会堵塞SQL线程）

自定义脚本

另有如下几个脚本需自定义，可实现一些更加高级的功能：

1. master_ip_failover：VIP故障转移

2. master_ip_online_change：VIP手动在线转移

3. send_report：当发生故障切换时，可通过send_report脚本发送告警信息。

4. power_manager:关闭服务器

可以通过如下链接下载

https://github.com/yoshinorim/mha4mysql-manager/tree/master/samples/scripts

3. 参考资料

https://www.percona.com/blog/2016/09/02/mha-quickstart-guide/

http://www.ttlsa.com/mysql/step-one-by-one-deploy-mysql-mha-cluster/

https://www.cnblogs.com/ivictor/p/5686275.html

https://andblog.cn/?p=974