简介

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，在MySQL故障切换过程中，MHA能够做到0~30秒之内完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到正真意义上的高可用。

该软件由两部分组成：

MHA Manager：管理节点（主要包括以下几个工具）

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

MHA Node：数据节点（主要包括以下几个工具）

下面的这些工具通常由MHA Manager中的脚本触发，无需人为操作

• save_binary_logs：保存和复制master的二进制日志
• apply_diff_relay_logs：识别差异的中继日志事件，并将差异的事件应用于其它slave
• purge_relay_logs：清除中继日志（purge_relay_logs脚本在不会阻塞SQL线程情况下自动清理relaylog ）

MHA Manager可以单独部署在一*立的主机上管理多个 master-slave 集群，也可以部署在一台 slave 节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的 master 节点，当 master 出现故障时，它可以自动将拥有 master 最新数据的 slave 提升为新的 master，然后将所有其它的 slave 重新指向新的 master。整个故障转移过程对应用程序完全透明。

目前MHA主要支持一主多从的架构，要搭建MHA，要求一个复制集群中必须最少有三台数据库服务器，一主二从（不支持单机多实例）。即一台充当 master，一台 slave 充当备用 master，另外一台完全为slave（MHA Manager 管理节点可以使用此slave）。

TIP：为了满足和我一样爱刨根问底的小伙伴的好奇心，这里说一下，为啥一个复制集群需要至少三台服务器？

上面说了，MHA有两部分组成：MHA Manager管理节点和MHA Node数据节点

MHA Node数据节点需要构建主从，那么至少需要两台机器（至于为甚不支持单机多实例，下面会涉及），一台作为 master，一台作为 slave。那么MHA Manager 管理节点往哪里放呢？

有朋友肯定会说：“放在 master 节点上啊。”那 master 节点一旦损坏，MHA Manager管理节点也就无法工作了，那使用MHA高可用架构就没有意义了。

有朋友又会说：“放在 slave 节点上，master 出现故障，MHA Manager管理节点一样可以使用。”可是，master 出现故障后，MHA Manager管理节点就会挑选一台 slave 主机成为新的 master，那选谁呢？所以使用MHA高可用架构，一个复制集必须要3个独立服务器

PS：因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。

                                                                                                                                                                                            MHA架构示意图

 

MHA工作流程

下面的流程，就是masterha_manager做的事情

1、验证复制设置以及确认当前master 状态

• 连接所有hosts，MHA自动来确认当前master 是哪个，配置文件中无需指定哪个是master
• 如果其中有任何一个slave 挂了，脚本立即退出，停止监控
• 如果有一些必要的脚本没有在MHA Node节点安装，那么MHA在这个阶段终止，且停止监控

2、监控master

• 监控master，直到master挂掉

这个阶段，MHA不会监控slave。"stopping/restarting/adding/removing"操作在slave上，不会影响当前MHA监控进程。（当你添加或者删除slave 的时候，请更新好配置文件，最好重启MHA）

3、检测master 是否失败

• 如果MHA Manager 在三次间隔时间都没办法连接master server，就会进入这个阶段
• 如果设置了 secondary_check_script，那么MHA 会调用脚本做二次检测来判断master 是否真的挂了

 

接下来的步骤，就是masterha_master_switch的工作流程

4、再次验证slave 的配置

• 如果发现任何不合法的复制配置（如：有些slave的master不是同一个），那么MHA会停止监控，且报错。可通过在相应的slave节点下配置ignore_faile参数忽略

  ignore_fail：默认情况下，MHA在做故障转移的时候，会去检测所有的server，如果发现有任何的从库有问题（比如不能通过SSH检测主机或者mysql的存活，或者说有SQL线程复制错误等）就不会进行故障转移操作，但是，有时候可能需要在特定从库有故障的情况下，仍然继续进行故障转移，就可以使用这个参数指定它。默认是0，需要设置时在对应服务器的配置段下添加ignore_fail=1

  这一步是出于安全考虑。很有可能复制的配置文件已经被改掉了，所以double check是比较推荐的做法。
• 检查最后一次failover（故障转移）的状态。

  如果上一次的failover报错，或者上一次的failover结束的太近（默认3天），MHA停止监控，停止failover，那么在masterha_manager命令中设置ignore_last_failover，wait_on_failover_error来改变这一检测
  
  这么做，也是出于安全考虑。频繁的failover，检查下是否网络出问题，或者其他错误呢？

   

5、选主（当一个复制集中 master 出现故障时，MHA Manager   管理节点就会在复制集中进行选主）

   分为两种情况：

（1）master 所在的物理机彻底报废，再也不能访问：

• 因为每个slave都是异步拉取 binlog 的原因。relaylog 通常会晚于（少于）master 的 binlog 一些记录，所以slave 和master 之间的数据会不一致，且不同的slave 之间数据落后程度也会不一样。当master 机器挂掉后，slave 和master 之间的数据差异无法靠同步来弥补了，只能丢掉这一本分数据
• slave 之间数据落后的程度不同，这意味着有的slave 的 relaylog 中数据多一点，有的relaylog 中数据少一点，总之大家的数据不一致
• 为了最大程度挽救数据，我们等待所有slave 上的relaylog 执行完毕（如：i1），然后看一下每个slave 上的master-info.log（记录了拷贝master binlog 的最后偏移量），选最新的那个slave（如：Latest Slave）作为数据其它slave 数据恢复的标杆，将它拥而其它slave 因复制落后而没有的relaylog 数据，同步到其它slave 上
• 每个slave 将缺失的relaylog 回放执行，最终所有的slave 数据完全一致的
• 此后，按照配置文件顺序进行选主；如果配置文件中设定有权重（如：candidate_master=1）那么就会按照权重强制指定备选主

TIP：

    i、默认情况下，如果一个slave 落后master 的binlog 数据在100M以上的话，即使此slave 有权重，也会失效

    ii、如果配置文件中某个slave 节点配置了check_repl_delay=0，那么即使此slave 落后很多数据，MHA Manager也会强制将其选择围殴备选主

（2）master 只是进程退出，物理机还可以访问：

• 除了上述将slave 之间的差异抹平之外，还可以再次访问master 的物理主机
• 获取master 的binlog 文件偏移量，与抹平后的relaylog 偏移量之间的数据差异，得到一段diff 的binlog（apply_diff_relay_logs）
• 将这段diff 的binlog 应用到所有slave 上回放，那么所有slave 的数据将和master 完全一致。

 

6、应用透明（VIP）

  master 宕机后，VIP飘移到新选定master 上，这样外部访问同样的网址时，由新选定的master 提供服务，在外部看来似乎一切都没有变

7、故障切换通知

因为MHA 为一次性高可用产品，即监控的主库一旦宕机，完成VIP切换后，MHA也就不再工作了。所以需要发送邮件提醒，重新部署一下MHA

8、额外的数据补偿

此步骤主要针对的是master 宕机时，物理机也无法访问的情况。由于无法访问master 的物理机，那么可能就会有部分binlog 数据丢失，所以需要有额外的节点专门用于实时同步主库的数据，此节点不用于对外服务

 

MHA环境搭建

规划：

主库j节点：x.x.x.1  

从库节点：x.x.x.2    x.x.x.3

Manager节点：x.x.x.3

1、所有节点都配置配置关键程序软连接

例如：
[root@db01 ~] #ln -s /application/mysql/bin/mysqlbinlog    /usr/bin/mysqlbinlog
[root@db01 ~] #ln -s /application/mysql/bin/mysql          /usr/bin/mysql

#有朋友可能要问了，明明在PATH环境变量中添加了"/application/mysql/bin"路径，为啥还要创建软连接。
#这是因为MHA在使用"mysqlbinlog"、"mysql"这个命令时，只会去"/usr/bin"目录下去找

2、配置互信

[root@db01 ~] # rm -rf /root/.ssh/*         #删除原有的公钥和私钥文件
[root@db01 ~] # ssh-keygen -t dsa           #生成新的密钥
[root@db01 .ssh] # mv id_rsa.pub authorized_keys     #将公钥文件该为已经认证的密钥文件，这样就可以省略主机之间互相公钥认证了
[root@db01 ~] # scp  -r  /root/.ssh  x.x.x.1:/root     #将存放密钥的目录拷贝到slave1中
[root@db01 ~] # scp  -r  /root/.ssh  x.x.x.2:/root     #将存放密钥的目录拷贝到slave2中

各节点验证：
db01:
[root@db01 ~] ssh x.x.x.1 date
[root@db01 ~] ssh x.x.x.2 date
[root@db01 ~] ssh x.x.x.3 date
db02:
[root@db02 ~] ssh x.x.x.1 date
[root@db02 ~] ssh x.x.x.2 date
[root@db02 ~] ssh x.x.x.3 date
db03:
[root@db02 ~] ssh x.x.x.1 date
[root@db02 ~] ssh x.x.x.2 date
[root@db02 ~] ssh x.x.x.3 date

#一定要验证一下，因为使用密钥进行SSH连接的话，第一次需要输入密码，这样以后就不需要再使用密码交互式的连接了。

PS：为什么要配置互信？

因为当主库出现故障的时候，MHA Manager管理节点需要从从库中选出一个作为新的主库。若是旧的主库中有些 binlog 数据还没来得及传到新的主库中，这时就需要MHA免交互连接旧的主库，将还没有传递过来的binlog 数据同步到新的主库中。所以需要配置互信才可以免交互操作。

3、安装软件

i、下载MHA软件

mha官网：https://code.google.com/archive/p/mysql-master-ha/
github下载地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads

ii、所有Node节点安装mha-node软件包及依赖包

例如：
[root@db01 ~] # yum install perl-DBD-MySQL -y
[root@db01 ~] # rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm

iii、在主库db01中创建mha用户，此用户作为MHA服务的管理用户

mysql>  grant all privileges on *.* to mha@'x.x.x.%' identified by 'mha';

iv、在Manager(db03)安装mha-manager软件及依赖包

[root@db03 ~] # yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
[root@db03 ~] # rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm

4、Manager管理节点的配置文件配置

[root@db03 ~] # mkdir -p /etc/mha            #创建配置文件目录
[root@db03 ~] # mkdir -p /var/log/mha/app1   #创建日志目录
[root@db03 ~] # vim /etc/mha/app1.cnf        #编辑mha配置文件
      [server default]
manager_log=/var/log/mha/app1/manager        
manager_workdir=/var/log/mha/app1            
master_binlog_dir=/data/binlog    #所有节点的二进制日志都必须打开，文件名最好也都配置相同，方便管理 
user=mha                          #mha服务的管理用户        
password=mha                      #mha管理用户的密码
ping_interval=2                   #ping间隔时长
repl_password=123                 #数据库密码
repl_user=repl                    #数据库用户名
ssh_user=root                     #基于ssh的密钥认证，root为互信的用户，当然也可以指定其它的用户
[server1]                         #节点之间注意排列顺序，旧的主库宕机后，在没有配置权重的情况下，默认根据排列的顺序选择新的主库          
hostname=x.x.x.1
ssh_port=22                       #节点的ssh端口。若是默认的22端口，此参数可不用添加
port=3306                                  
[server2]            
hostname=x.x.x.2
port=3306
[server3]
hostname=x.x.x.3
port=3306

5、状态检查

[root@db03 ~]# masterha_check_ssh  --conf=/etc/mha/app1.cnf   #在MHA Manager管理节点互信检查
Fri Apr 19 16:39:34 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Fri Apr 19 16:39:34 2019 - [info] Reading application default configuration from /etc/mha/app1.cnf..
Fri Apr 19 16:39:34 2019 - [info] Reading server configuration from /etc/mha/app1.cnf..
Fri Apr 19 16:39:34 2019 - [info] Starting SSH connection tests..
Fri Apr 19 16:39:35 2019 - [debug] 
Fri Apr 19 16:39:34 2019 - [debug]  Connecting via SSH from root@10.0.0.51(10.0.0.51:22) to root@10.0.0.52(10.0.0.52:22)..
Fri Apr 19 16:39:34 2019 - [debug]   ok.
Fri Apr 19 16:39:34 2019 - [debug]  Connecting via SSH from root@10.0.0.51(10.0.0.51:22) to root@10.0.0.53(10.0.0.53:22)..
Fri Apr 19 16:39:35 2019 - [debug]   ok.
Fri Apr 19 16:39:36 2019 - [debug] 
Fri Apr 19 16:39:35 2019 - [debug]  Connecting via SSH from root@10.0.0.52(10.0.0.52:22) to root@10.0.0.51(10.0.0.51:22)..
Fri Apr 19 16:39:35 2019 - [debug]   ok.
Fri Apr 19 16:39:35 2019 - [debug]  Connecting via SSH from root@10.0.0.52(10.0.0.52:22) to root@10.0.0.53(10.0.0.53:22)..
Fri Apr 19 16:39:35 2019 - [debug]   ok.
Fri Apr 19 16:39:37 2019 - [debug] 
Fri Apr 19 16:39:35 2019 - [debug]  Connecting via SSH from root@10.0.0.53(10.0.0.53:22) to root@10.0.0.51(10.0.0.51:22)..
Fri Apr 19 16:39:35 2019 - [debug]   ok.
Fri Apr 19 16:39:35 2019 - [debug]  Connecting via SSH from root@10.0.0.53(10.0.0.53:22) to root@10.0.0.52(10.0.0.52:22)..
Fri Apr 19 16:39:36 2019 - [debug]   ok.
Fri Apr 19 16:39:37 2019 - [info] All SSH connection tests passed successfully.
******************************************************************************************************************
*******************************************************************************************************************
[root@db03 ~]# masterha_check_repl  --conf=/etc/mha/app1.cnf   #主从状态检查
Fri Apr 19 16:40:50 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Fri Apr 19 16:40:50 2019 - [info] Reading application default configuration from /etc/mha/app1.cnf..
Fri Apr 19 16:40:50 2019 - [info] Reading server configuration from /etc/mha/app1.cnf..
Fri Apr 19 16:40:50 2019 - [info] MHA::MasterMonitor version 0.56.
Fri Apr 19 16:40:51 2019 - [info] GTID failover mode = 1
Fri Apr 19 16:40:51 2019 - [info] Dead Servers:
Fri Apr 19 16:40:51 2019 - [info] Alive Servers:
Fri Apr 19 16:40:51 2019 - [info]   10.0.0.51(10.0.0.51:3306)
Fri Apr 19 16:40:51 2019 - [info]   10.0.0.52(10.0.0.52:3306)
Fri Apr 19 16:40:51 2019 - [info]   10.0.0.53(10.0.0.53:3306)
Fri Apr 19 16:40:51 2019 - [info] Alive Slaves:
Fri Apr 19 16:40:51 2019 - [info]   10.0.0.52(10.0.0.52:3306)  Version=5.7.20-log (oldest major version between slaves) log-bin:enabled
Fri Apr 19 16:40:51 2019 - [info]     GTID ON
Fri Apr 19 16:40:51 2019 - [info]     Replicating from 10.0.0.51(10.0.0.51:3306)
Fri Apr 19 16:40:51 2019 - [info]   10.0.0.53(10.0.0.53:3306)  Version=5.7.20-log (oldest major version between slaves) log-bin:enabled
Fri Apr 19 16:40:51 2019 - [info]     GTID ON
Fri Apr 19 16:40:51 2019 - [info]     Replicating from 10.0.0.51(10.0.0.51:3306)
Fri Apr 19 16:40:51 2019 - [info] Current Alive Master: 10.0.0.51(10.0.0.51:3306)
Fri Apr 19 16:40:51 2019 - [info] Checking slave configurations..
Fri Apr 19 16:40:51 2019 - [info]  read_only=1 is not set on slave 10.0.0.52(10.0.0.52:3306).
Fri Apr 19 16:40:51 2019 - [info]  read_only=1 is not set on slave 10.0.0.53(10.0.0.53:3306).
Fri Apr 19 16:40:51 2019 - [info] Checking replication filtering settings..
Fri Apr 19 16:40:51 2019 - [info]  binlog_do_db= , binlog_ignore_db= 
Fri Apr 19 16:40:51 2019 - [info]  Replication filtering check ok.
Fri Apr 19 16:40:51 2019 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Fri Apr 19 16:40:51 2019 - [info] Checking SSH publickey authentication settings on the current master..
Fri Apr 19 16:40:51 2019 - [info] HealthCheck: SSH to 10.0.0.51 is reachable.
Fri Apr 19 16:40:51 2019 - [info] 
10.0.0.51(10.0.0.51:3306) (current master)
 +--10.0.0.52(10.0.0.52:3306)
 +--10.0.0.53(10.0.0.53:3306)
Fri Apr 19 16:40:51 2019 - [info] Checking replication health on 10.0.0.52..
Fri Apr 19 16:40:51 2019 - [info]  ok.
Fri Apr 19 16:40:51 2019 - [info] Checking replication health on 10.0.0.53..
Fri Apr 19 16:40:51 2019 - [info]  ok.
Fri Apr 19 16:40:51 2019 - [warning] master_ip_failover_script is not defined.
Fri Apr 19 16:40:51 2019 - [warning] shutdown_script is not defined.
Fri Apr 19 16:40:51 2019 - [info] Got exit code 0 (Not master dead).
MySQL Replication Health is OK.

6、开启MHA服务（db03）

[root@db03 ~] # nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

#--remove_dead_master参数：在master 宕机后，会将配置文件中关于master的节点的信息删除掉
#--ignore_last_failover参数：如果上一次failover刚刚才完成（默认8小时），那么MHA Manager这次将不会进行failover,主要是为了避免ping-pong failover 或只是简单的网络问题导致的MHA服务不可用。若是使用了--ignore_last_failover参数，就会忽略这个限制

tip：后台运行MHA服务，让MHA Manager管理节点一直处于运行的状态，关于后台运行的知识点可参考此篇博客：传送门

7、查看MHA服务状态

[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:4719) is running(0:PING_OK), master:10.0.0.51

[root@db03 ~]# mysql -umha -pmha -h x.x.x.1 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 51    |
+---------------+-------+

[root@db03 ~]# mysql -umha -pmha -h x.x.x.2 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 52    |
+---------------+-------+

[root@db03 ~]# mysql -umha -pmha -h x.x.x.3 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 53    |
+---------------+-------+

MHA引用透明（MHA+KeepAlive）

master 宕机后，VIP飘移到新选定master 上，这样外部访问同样的网址时，由新选定的master 提供服务，在外部看来似乎一切都没有变。

MHA自带VIP切换脚本：master_ip_failover.txt

此脚本可以放置到任意位置，但是官方放在了"/usr/local/bin/"路径下，所以阿静VIP脚本复制到此脚本下

VIP切换脚本配置

（1）修改VIP切换脚本

在MHA Manager管理节点配置VIP切换脚本
[root@db03 ~]# cp /root/master_ip_failover.txt /usr/local/bin/master_ip_failover
[root@db03 ~]# vim /usr/local/bin/master_ip_failover   
           ...
   my $vip = '10.0.0.55/24';     #指定一个地址为VIP地址。对外提供服务的地址
   my $key = '1';    
   my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";     #生成vip地址；在Linux命令行手工生成子网卡地址：ifconfig eth0:1 10.0.0.55/24 然后查看ip就会看到新生成的子网卡地址。若是想删除子网卡地址，使用命令：ifconfig eth0:1 down
   my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";      #主库宕机时，需要将VIP下线
           ...
  
#tip：master_ip_failover.txt脚本中只需要修改以上的内容，其它内容无需修改。
***************************************************************************************************************

[root@db03 bin]# yum install -y  dos2unix

[root@db03 bin]# dos2unix /usr/local/bin/master_ip_failover   # dos2unix命令用来将DOS格式的文本文件转换成UNIX格式的（master_ip_failover脚本是在windows下写的，在linux中使用，要先转换一下格式）

[root@db03 bin]# chmod +x /usr/local/bin/master_ip_failover   #让master_ip_failover脚本可执行

[root@db03 bin]# vim /etc/mha/app1.cnf          #在MHA服务的配置文件中配置VIP切换脚本
   master_ip_failover_script=/usr/local/bin/master_ip_failover

关于物理网卡、子网卡、虚拟VLAN网卡的关系可参考此篇博客：传送门

关于dos2unix命令可参考此篇博客：传送门

（2）手工添加VIP

[root@db01 ~]# ifconfig eth0:1 10.0.0.55/24

#因为db01是master server,MHA服务刚开始运行时是不会在master server上自动创建VIP的，
#只有当Failover时，MHA服务才会调用 master_ip_failover脚本在新的master server上创建VIP，从而实现VIP的切换

（3）重启MHA服务

[root@db03 bin]# masterha_stop --conf=/etc/mha/app1.cnf

[root@db03 bin]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

[root@db03 bin]# masterha_check_status --conf=/etc/mha/app1.cnf  #查看当前server是主库还从库
app1 (pid:14410) is running(0:PING_OK), master:10.0.0.51

 

MHA故障提醒

因为MHA为一次性高可用产品，即监控的主库一旦宕机，完成VIP切换后，MHA也就不再工作了。所以需要发送邮件提醒，重新部署一下MHA。

1、下载sendEmail（当然也可以使用mailx服务）

下载地址：
http://caspian.dotconf.net/menu/Software/SendEmail/sendEmail-v1.56.tar.gz

2、配置sendEamil服务

将下载到windows中的sendEmail文件上传到Linux中。
[root@db03 ~]# tar -xvf sendEmail-v1.56.tar.gz    #解压文件
[root@db03 ~]# cp /sendEmail-v1.56/sendEmail  /usr/local/bin/    #将sendEmail服务拷贝到/usr/local/bin/目录下，主要就是为了和master_ip_failover脚本放在一起，方便管理，也可以放在别的地方
[root@db03 ~]# cd /usr/local/bin
[root@db03 bin]# touch testpl     #创建testpl文件，此文件的功能就是使用sendEmail服务发送邮件，定义了邮件转发的邮箱、目的邮箱以及邮件内容
  #!/bin/bash                                                                      
  /usr/local/bin/sendEmail -o tls=no -f g_lee0916@126.com -t 22654481@qq.com -s smtp.126.com:25 -xu g_lee0916 -xp ybbhlkg1dddf -u "MHA Waring" -m "YOUR MHA MAY BE FAILOVER" &>/tmp/sendmail.log

[root@db03 bin]# touch send       #创建send文件，调用testpl文件
    #! /usr/bin/perl -w                                                              
    system"testpl"

[root@db03 bin]# chmod +x *    #给予这些文件可执行权限 

[root@db03 ~]# vim /etc/mha/app1.cnf      #在MHA服务的配置文件中指定故障提醒的脚本
    report_script=/usr/local/bin/send  
                              

#sendEmail服务的参数说明：
参数说明

-f 表示发送者的邮箱（即转发邮箱）

-t 表示接收者的邮箱

-s 表示SMTP服务器的域名或者ip

-u 表示邮件的主题

-xu 表示SMTP验证的用户名

-xp 表示SMTP验证的密码(注意,这个密码是你使用的邮箱开启SMTP时生成的密码，并不是自己设置的密码)

-m 表示邮件的内容

-cc 表示抄送

-bcc 表示暗抄送

3、重启MHA

[root@db03 ~]# masterha_stop --conf=/etc/mha/app1.cnf

[root@db03 ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

 

额外的数据补偿

此步骤主要针对的是master 宕机时，物理机也无法访问的情况。由于无法访问master 的物理机，那么可能就会有部分binlog 数据丢失，所以需要有额外的节点专门用于实时同步主库的数据，此节点不用于对外服务。

1、找到一台额外的MySQL服务器，必须是MySQL 5.6版本以上，支持gtid。

[root@db03 ~]#vim /etc/mha/app1.cnf    #在MHA服务的配置文件中配置一个binlog1节点
      ...
  [binlog1]
  no_master=1         #表示不参与选主
  hostname=x.x.x.4
  master_binlog_dir=/data/mysql/binlog    #用于保存主库的binlog数据，要和主库的master_binlog_dir路径区分开

2、创建必要的目录

在新的节点db04中操作：
[root@db04 ~]# mkdir -p /data/mysql/binlog
[root@db04 ~]# chown -R mysql.mysql /data/*

3、拉取master 的binlog 日志

[root@db04 ~]# cd /data/mysql/binlog    #进入到自己创建的目录中
 
[root@db04 binlog]# mysqlbinlog  -R --host=10.0.0.51 --user=mha --password=mha --raw  --stop-never mysql-bin.000001 &
#对master 中的binlog数据进行实时数据拉取。使用这种方式进行同步主库的binlog数据时，只有主库的事务的binlog数据被拉取过来并刷新到磁盘上后，主库的事务才能commit成功，以此来避免主从备份那样会产生数据延迟

tip：真实的生产环境中，拉取日志的起点，需要按照目前master 正在使用的binlog 文件为起点

4、重启MHA服务

[root@db03 bin]# masterha_stop --conf=/etc/mha/app1.cnf

[root@db03 bin]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

 

故障模拟及故障处理

1、宕掉master 的mysqld 线程

[root@db01 ~]# pkill mysqld     #杀掉mysqld线程，MySQL服务宕机

2、恢复故障

i、启动故障节点
[root@db01 ~]# systemctl start mysqld   #启动MySQL服务

ii、恢复主从关系
[root@db03 bin]# grep "CHANGE MASTER TO"  /var/log/mha/app1/manager    #通过查看MHA服务的日志信息，就可以获取MHA Manager管理节点已经将哪个节点作为新的master
Thu Jul 18 18:31:54 2019 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST=x.x.x.2', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='xxx';

[root@db01 ~]# mysql -uroot -p     #此时新的master 为'x.x.x.2'主机，旧的master (db01)主机只能作为slave节点了，所以需要告诉旧master(db01)要从哪里开始拉取新的master 的binlog
   ...
   mysql> CHANGE MASTER TO MASTER_HOST='10.0.0.52', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='xxx';
   ...
   mysql> start slave;

3、恢复MHA服务配置文件 。因为主库一旦宕机后，MHA Manager 管理节点就会将旧master 的信息在配置文件中删除

[root@db03 bin]# vim /etc/mha/app1.cnf
      ...
   [server1]
   hostname=10.0.0.51
   port=3306
   [server2]
   hostname=10.0.0.52
   port=3306
   [server3]
   hostname=10.0.0.53
   port=3306
     ...

4、启动MHA服务

[root@db03 bin]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
[1] 16543
[root@db03 bin]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:16543) is running(0:PING_OK), master:10.0.0.52

5、恢复binlog server

若是旧master 依旧可以访问，那么MHA服务会自动将旧master 中的binlog数据拉取到新的master中进行数据
回放；
若是旧master 不可以访问了，那就需要从binlog server 中获取相应的binlog 数据在新的master 中进行数据回放；

这种两中情况结束后，都需要将binlog server 中的数据删除，从新拉取新的master中的binlog 数据。

[root@db04 ~]# cd /data/mysql/binlog    
[root@db04 binlog]# rm -rf /data/mysql/binlog/*
[root@db04 binlog]# mysqlbinlog  -R --host=10.0.0.52 --user=mha --password=mha --raw  --stop-never mysql-bin.000001 &

 

参考文章：

https://developer.aliyun.com/article/58004?spm=a2c6h.14164896.0.0.7bd3bd735t1YHb

https://blog.51cto.com/13560168/2393037