简介

MHA（Master HA）是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automating master failover 功能。MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的 slave 节点成为新的master 节点，在此期间，MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题。MHA 还提供了 master 节点的在线切换功能，即按需切换 master/slave 节点。
MHA 是由日本人 yoshinorim（原就职于DeNA现就职于FaceBook）开发的比较成熟的 MySQL 高可用方案。MHA 能够在30秒内实现故障切换，并能在故障切换中，最大可能的保证数据一致性。目前淘宝也正在开发相似产品TMHA，目前已支持一主一从。

MHA 服务有两种角色， MHA Manager(管理节点)和 MHA Node(数据节点)：

MHA Manager：
- 通常单独部署在一台独立机器上管理多个 master/slave 集群(组)，每个 master/slave 集群称作一个 application，用来管理统筹整个集群。
MHA node：
- 运行在每台 MySQL 服务器上(master/slave/manager)，它通过监控具备解析和清理 logs 功能的脚本来加快故障转移。
- 主要是接收管理节点所发出指令的代理，代理需要运行在每一个 mysql 节点上。简单讲 node 就是用来收集从节点服务器上所生成的 bin-log 。

特点：
1.自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据不丢失；
2.使用半同步复制，可以大大降低数据丢失的风险，如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性

工作过程：
1.从宕机崩溃的 Master 保存二进制日志事件（binlog event）；
2. 识别含有最新更新的 Slave；
3. 应用差异的中继日志（relay log）到其他 Slave；
4. 应用从 Master 保存的二进制日志事件；
5. 提升一个 Slave 为新的 Master；
6. 使其他的 Slave 连接新的 Master 进行复制；

案例：MHA实现MySQL高可用架构

准备环境

机器名称	IP配置	服务角色	备注
Manager	192.168.80.10	Manager控制器	用于监控管理
master	192.168.80.20	数据库主服务器	开启bin-log，relay-log 关闭relay_log_purge
slave1	192.168.80.30	数据库从服务器	开启bin-log，relay-log 关闭relay_log_purge
slave2	192.168.80.40	数据库从服务器	开启bin-log，relay-log 关闭relay_log_purge

在各节点的/etc/hosts文件中添加以下内容：

192.168.80.10 server1.mha.com server1
192.168.80.20 server2.mha.com server2
192.168.80.30 server3.mha.com server3
192.168.80.40 server4.mha.com server4

这样我们就可以通过host解析节点来打通私钥访问。
关闭各节点防火墙和selinux

systemctl stop firewalld
setenforce 0

配置主节点master

[root@server2 ~]# yum install mariadb-server -y
[root@master ~]# vim /etc/my.cnf
    server-id = 1                //复制集群中的各节点的id均必须唯一
    log-bin = master-log        //开启二进制日志
    relay-log = relay-log        //开启中继日志
    skip_name_resolve            //关闭名称解析（非必须）

$1QRL`BJCJ3S~{LQ)6UN_F40.png$

配置从节点slave

[root@server2~]# vim /etc/my.cnf
    [mysqld]
    server-id = 2                 //复制集群中的各节点的id均必须唯一；
    relay-log = relay-log        //开启中继日志
    log-bin = master-log        //开启二进制日志
    read_only = ON                //启用只读属性
    relay_log_purge = 0            //是否自动清空不再需要中继日志
    skip_name_resolve            //关闭名称解析（非必须）
    log_slave_updates = 1       //使得更新的数据写进二进制日志中
[root@server2 ~]# systemctl restart mariadb

[root@server3 ~]# vim /etc/my.cnf
    [mysqld]
    server-id = 3                 //复制集群中的各节点的id均必须唯一；
    relay-log = relay-log        //开启中继日志
    log-bin = master-log        //开启二进制日志
    read_only = ON                //启用只读属性
    relay_log_purge = 0            //是否自动清空不再需要中继日志
    skip_name_resolve            //关闭名称解析（非必须）
    log_slave_updates = 1       //使得更新的数据写进二进制日志中
[root@server3 ~]# systemctl restart mariadb

配置一主多从架构

master节点

MariaDB [(none)]> grant replication slave,replication client on *.* to root@'%' identified by '1';
MariaDB [(none)]> flush privileges;
MariaDB [(none)]> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 |      399 |              |                  |
+------------------+----------+--------------+------------------+

slave节点

MariaDB [(none)]> change master to master_host='192.168.80.20',
  -> master_user='root',
  -> master_password='1',
  -> master_log_file='mysql-bin.000003',
  -> master_log_pos=399;
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status\G;

安装配置MHA

给master授权

在MySQL节点授权，拥有权限的用户可以在本地网络中的其他远程节点访问。

MariaDB [(none)]> grant all on *.* to 'mhaadmin'@'%' identified by '1';

准备ssh互通环境

MHA集群中各节点需要通过SSH互相通信，以实现远程控制和数据管理功能。在Manager节点设置密钥对，设置为可以远程连接主机后，将密钥对复制给其余所有节点。

# 在所有节点上执行以下命令
[root@server1 ~]# ssh-keygen -t rsa
[root@server1 ~]# ssh-copy-id -i .ssh/id_rsa.pub root@192.168.80.10

当四台机器都进行上述操作后，可以在manager节点查看authorized_keys

[root@server1 ~]# cat .ssh/authorized_keys

四台机器的公钥都已经在authorized_keys这个文件里了，接下来把这个文件发送给其他三台机器就可以实现SSH互相通信了。

[root@server1 ~]# scp .ssh/authorized_keys  root@192.168.80.20:/root/.ssh/

安装MHA包

四个节点都需安装：mha4mysql-node-0.56-0.el6.norch.rpm
manager节点需要另外安装：mha4mysql-manager-0.56-0.el6.noarch.rpm
使用rz命令上传，使用yum安装。

[root@server1 ~]# rz
[root@server1 ~]# yum install mha4mysql-node-0.56-0.el6.noarch.rpm -y 
[root@server1 ~]# yum install epel-release.noarch -y  # manager需要扩展源依赖
[root@server1 ~]# yum install mha4mysql-manager-0.56-0.el6.noarch.rpm -y

初始化MHA，进行配置

Manager 节点需要为每个监控的 master/slave 集群提供一个专用的配置文件，而所有的 master/slave 集群也可共享全局配置。如果仅监控一组 master/slave 集群，也可直接通过 application 的配置来提供各服务器的默认配置信息。而每个 application 的配置文件路径为自定义。
为MHA专门创建一个管理用户，方便以后使用，在mysql的主节点上，三个节点自动同步：


[server default]             //适用于server1,2,3个server的配置
user=mhaadmin                 //mha管理用户
password=1             //mha管理密码
manager_workdir=/etc/mha_master/app1         //mha_master自己的工作路径
manager_log=/etc/mha_master/manager.log     // mha_master自己的日志文件
remote_workdir=/mydata/mha_master/app1        //每个远程主机的工作目录在何处
ssh_user=root                 // 基于ssh的密钥认证
repl_user=root                //数据库用户名
repl_password=1        //数据库密码
ping_interval=1             //ping间隔时长
[server1]                     //节点2
hostname=192.168.80.20     //节点2主机地址
ssh_port=22                 //节点2的ssh端口
candidate_master=1             //将来可不可以成为master候选节点/主节点
[server2]
hostname=192.168.80.30
ssh_port=22
candidate_master=1
[server3]
hostname=192.168.80.40
ssh_port=22
candidate_master=1

对四个节点进行检测

（1）检测各节点ssh互相通信配置是否正确
在Manager机器上输入命令：

[root@server1 ~]# masterha_check_ssh -conf=/etc/mha_master/mha.cnf

如果最后一行显示[info]All SSH connection tests passed successfully.则表示成功
（2）检查管理MySQL复制集群的连接配置参数是否正确

masterha_check_repl -conf=/etc/mha_master/mha.cnf

我们发现检测失败，这可能是因为从节点上没有账号，因为这个架构，任何一个从节点，将有可能成为主节点，所以也需要创建账号。
因此，我们需要在master节点上再次执行以下操作：

MariaDB [(none)]> grant replication slave,replication client on *.* to root@'%' identified by '1';
MariaDB [(none)]> flush privileges;

启动MHA

在Manager节点执行命令：

[root@server1 ~]# nohup masterha_manager -conf=/etc/mha_master/mha.cnf &> /etc/mha_master/manager.log &
[1] 7743

启动成功后来查看一下master节点的状态

[root@server1 ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha (pid:7743) is running(0:PING_OK), master:192.168.80.20

如果，我们想要停止 MHA ，则需要使用 stop 命令：

masterha_stop -conf=/etc/mha_master/mha.cnf

测试故障转移

在Master节点关闭mariadb服务，模拟数据库崩溃

[root@server2 ~]# systemctl stop mariadb

在manager节点查看日志

tail -200 /etc/mha_master/manager.log

表示 manager 检测到192.168.80.20节点故障，而后自动执行故障转移，将192.168.80.30提升为主节点。
注意，故障转移完成后， manager将会自动停止，此时使用 masterha_check_status 命令检测将会遇到错误提示，如下所示：

[root@server1 ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha is stopped(2:NOT_RUNNING).

提供新的节点修复集群

原有 master 节点故障后，需要重新准备好一个新的 MySQL 节点。基于来自于master 节点的备份恢复数据后，将其配置为新的 master 的从节点即可。
注意，新加入的节点如果为新增节点，其 IP 地址要配置为原来 master 节点的 IP，否则，还需要修改 mha.cnf 中相应的 ip 地址。随后再次启动 manager ，并再次检测其状态。

我们就以刚刚关闭的那台主作为新添加的机器，来进行数据库的恢复：
原本的 slave1 已经成为了新的主机器，所以，我们对其进行完全备份，而后把备份的数据发送到我们新添加的机器上：

[root@server3 ~]# mkdir /backup
[root@server3 ~]# mysqldump --all-database > /backup/mysql-backup-`date +%F-%T`-all.sql
[root@server3 ~]# scp /backup/mysql-backup-2021-04-02-14\:46\:53-all.sql root@192.168.80.20:/root/

然后再server2上进行数据恢复

[root@server2 ~]# systemctl start mariadb
[root@server2 ~]# mysql < mysql-backup-2021-04-02-14\:46\:53-all.sql

配置主从

MariaDB [(none)]> change master to master_host='192.168.80.30',master_user='root',master_password='1',master_log_file='master-log.000005',master_log_pos=1587;
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status \G;

新节点提供后再次执行检查操作

[root@server1 ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf

如果报错，则再次授权（详见上文）。若没有问题，则启动 manager，注意，这次启动要记录日志：

[root@server1 ~]# masterha_manager -conf=/etc/mha_master/mha.cnf > /etc/mha_master/manager.log 2>&1 &
[1] 8124

启动成功以后，我们来查看一下 master 节点的状态：

[root@server1 ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha (pid:8124) is running(0:PING_OK), master:192.168.80.30

我们的服务已经成功继续了。

故障转移

1）在生产环境中，当你的主节点挂了后，一定要在从节点上做一个备份，拿着备份文件把主节点手动提升为从节点，并指明从哪一个日志文件的位置开始复制
2）每一次自动完成转换后，每一次的(replication health )检测不ok始终都是启动不了必须手动修复主节点，除非你改配置文件
3）手动修复主节点提升为从节点后，再次运行检测命令
masterha_check_status -conf=/etc/mha_master/mha.cnf
4）再次运行起来就恢复成功了