目录

• 一、mysql搭建MHA高可用集群
• • 1.环境部署
  • 2.高可用集群搭建
• 二、MHA的故障切换
• • 1.手动切换
  • 2.自动切换
  • 3.通过脚本切换

一、mysql搭建MHA高可用集群

1.环境部署

（配置：一主两从模式，当主服务器down掉，从服务器会自动切换为主服务器）
配置之前应该先停止server1/2/3的mysql数据库；
清除/data/mysql目录的数据


编辑master端（server1）的mysql配置文件


进行mysqld非安全初始化，重新生成/data目录

再启动mysql数据库

master端授予slave主机REPLICATION SLAVE权限，可以使用repl这个用户名和westos这个密码进行连接数据库;

查看数据库用户信息


查看db字段信息

编辑slave端（server2）的mysql配置文件


进行mysqld非安全初始化，重新生成/data 目录;
启动mysql数据库

进行CHANGE MASTER TO操作，以确定server2需要同步的主机IP，用户名，密码，使用基于GTID的复制；
启动slave

查看slave端状态

编辑slave端（server3）的mysql配置文件


进行mysqld非安全初始化，重新生成/data 目录 ;
启动mysql数据库

进行CHANGE MASTER TO操作，以确定server3需要同步的主机IP，用户名，密码，使用基于GTID的复制；
启动slave

server2进入数据库，可以查看到repl用户

对于server4，停止之前的mysql路由服务

从服务器获取MHA高可用所需安装包

2.高可用集群搭建

MHA是一套相对成熟的MySQL高可用方案，能做到在0~30s内自动完成数据库的故障切换操作，
在master服务器不宕机的情况下，基本能保证数据的一致性。
也就是说，当master down掉的时候，slave1顶替成为新的master，原来的master成为新的slave

server4需要安装如下rpm包，其依赖性包都在这个目录

所以直接执行如下指令

server4将如下rpm包传给mysql各个节点

• 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线程）

server1/2/3安装rpm包（使用yum install 可以解决依赖性问题）



rpm –ql：可以看到指定 rpm 包安装的详细路径

MHA Manager服务器需要为每个监控的Master/Slave集群提供一个专用的配置文件，而所有的Master/Slave集群也可以共享全局配置。

在管理节点 server4 上进行下面配置；
创建配置文件目录，编写app1.conf配置文件

配置文件的内容格式可以参考如下；
解压如下tar包

查看samples目录下的conf目录下的文件

app1.cnf 文件内容解释如下：
manager_workdir=/var/log/masterha/app1 ：MHA监控实例根目录
manager_log=/var/log/masterha/app1/manager.log ：MHA监控实例日志文件

[serverx] 服务器编号
hostname 主机名
candidate_master 可以做主库

1、candidate_master：从不同的从库服务器中，提升一个可靠的机器为新主库，可以通过在配置文件中对应的从库服务器的配置段下添加candidate_master=1来提升这个从库被提升为新主库的优先级（这个从库要开启binlog，以及没有显著的复制延迟，如果不满足这两个条件，也并不会在主库挂掉的时候成为新主库，所以，这个参数只是提升了优先级，并不是说指定了这个参数就一定会成为新主库）
2、 no_master：通过在目标服务器的配置段落设置no_master=1，它永远也不会变为新主库，用于配置在不想用于接管主库故障的从库上，注意，不能把所有的从库都配置这个参数，这样MHA检测到没有可用备主的时候，会中断故障转移操作

接下来配置监控全局配置文件app1.conf;

ping_interval=3 ：设置监控主库，发送ping包的时间间隔
secondary_check_script=/usr/bin/masterha_secondary_check -s xxx ：二次检查的主机，实现多路监测master的可用性

修改数据库密码（ %允许来自任何ip的连接，localhost允许本机的连接）；

客户端使用root身份、westos 密码进行连接测试，可以成功登录数据库

继续编辑配置文件，写入要监控的服务器；
设定表示，可以作为候选master，server3始终是slave；
candidate_master=1 ：指定failover时此slave会接管master，即使数据不是最新的。
check_repl_delay：默认情况下，如果从库落后主库100M的relay logs，MHA不会选择这个从库作为新主库，因为它会增加恢复的时间，设置这个参数为0，MHA在选择新主库的时候，则忽略复制延迟，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master

MHA配置检测：执行SSH通信检测
在MHA Manager服务器上执行，出现报错，是由于没有做主机SSH互通

当使用 ssh-keygen 产生公钥与私钥对之后，使用 ssh-copy-id 将本机的公钥复制到远程机器的 ~/ .ssh/authorized_key.文件中，:这样以后登录到远程主机就可以不用输入密码

将server1的/root/.ssh/id_rsa.pub 公钥复制给server2/3/4

检查四台机器之间是否ssh互通，各个机器都进行检查，如果不通，则通过ssh-copy-id命令将公钥复制给相应的机器




再次进行MHA配置检测：执行SSH通信检测

出现了成功的提示，说明SSH连接没有问题

检测MySQL主从复制，在MHA Manager服务器上执行：

出现了“MySQL Replication Health is OK.”说明集群没有问题

二、MHA的故障切换

1.手动切换

• MHA的故障切换过程，共包括以下的步骤：
  （1）配置文件检查阶段，这个阶段会检查整个集群配置文件配置
  （2）宕机的master处理，这个阶段包括虚拟ip摘除操作，主机关机操作
  （3）复制dead maste和最新slave相差的relay log，并保存到MHA Manger具体的目录下
  （4）识别含有最新更新的slave
  （5）应用从master保存的二进制日志事件（binlog events）
  （6）提升一个slave为新的master进行复制
  （7）使其他的slave连接新的master进行复制

• MHA在线切换的大概过程：
  1.检测复制设置和确定当前主服务器
  2.确定新的主服务器
  3.阻塞写入到当前主服务器
  4.等待所有从服务器赶上复制
  5.授予写入到新的主服务器
  6.重新设置从服务器

为了保证数据完全一致性，在最快的时间内完成切换，MHA的在线切换必须满足以下条件才会切换成功，否则会切换失败。
1.所有slave的IO线程都在运行
2.所有slave的SQL线程都在运行
3.所有的show slave status的输出中Seconds_Behind_Master参数小于或者等于running_updates_limit秒，如果在切换过程中不指定running_updates_limit,那么默认情况下running_updates_limit为1秒。
4.在master端，通过show processlist输出，没有一个更新花费的时间大于running_updates_limit秒。

手动切换，将当前集群mysql数据库的master切换为server2（这条指令是在作为master的server1状态完好时执行的）

都选择yes



可以看到切换成功的提示信息

server2进入数据库，执行 show slave master 返回错误，因为当前server2已经切换为了master，这条指令是用于提供有关从服务器线程的关键参数的信息

server1进入数据库，可以看到slave的状态，以及当前的master为server2

server3进入数据库，可以看到slave的状态，以及当前的master为server2

当我们停止server2的mysql数据库后

slave端查看状态就会出错


此时我们再次手动切换，将master切换为server1（这条指令是在作为master的server2 down 掉后执行的）



切换成功

然后 server1进入数据库，执行 show slave master 返回错误，因为当前server1已经切换为了master，这条指令是用于提供有关从服务器线程的关键参数的信息

server3进入数据库，可以看到slave的状态，以及当前的master为server1

我们将server2的数据库开启

server2进入数据库后要重新执行CHANGE MASTER TO操作，以确定需要同步的主机IP，用户名，密码，以及使用基于GTID的主从复制方式；
开启salve

2.自动切换

每次failover 切换后会在管理目录生成文件app1.failover.complete ，下次在切换的时候会发现有这个文件导致切换不成功（不会再进行主库的切换），需要手动清理掉。但是，也可以加上参数–ignore_last_failover 来启动mha manager

将 MHA Manager服务在后台启动


停止server1的mysql服务

当MHA Manager 的 进程执行完毕，会生成如下文件（此时就表明master已经切换成功了）


可以看到server2已经无法查看slave状态，因为它是master

server3查看slave状态

将server1的mysql服务启动

重新执行CHANGE MASTER TO操作

3.通过脚本切换

接下来我们将配置文件的mysqlfailover 参数打开，通过脚本进行自动切换；

mysqlfailover 是mysql utilities工具包中包含的一个重要的高可用命令，用于对主从复制架构进行健康检测以及实现故障自动转移。它会定期按指定的时间间隔探测各节点的健康状态，一旦在捕获到主节点不可用时，将触发故障转移相关动作，自动执行故障切换到当前最佳的从服务器上。同时整个主从架构内的其他从节点将指向新的主节点，自动完成主从拓扑结构更新。

首先应该将前一个实验自动切换完毕后生成的文件删掉

编辑配置文件；
#master_ip_failover_script=/usr/bin/master_ip_failover #failover自动切换脚本
#master_ip_online_change_script= /usr/local/bin/master_ip_online_change #手动切换脚本

server4从服务器获取failover自动/手动切换脚本，放到/etc/masterha目录下



赋予脚本可执行权限

编辑配置文件，设定vip（因为用户访问入口只能有一个，所以需要配置vip）



由于此时的master为server2，因此在server2上添加脚本设定的vip

客户端进行连接测试，可以登录数据库

进行手动切换，将master切换为server1



切换成功

客户端连接测试无误

可以看到vip已经不在server2上了

已经漂移到了server1上（server1是当前的master）

slave端查看状态


我们再次使用自动切换的方式，切换master


然后将当前master节点的mysql服务停止


可以看到vip 已经不在server1上了（说明此时自动切换已经完成）

客户端进行连接测试，仍能登录数据库

slave端查看状态

自动切换完成，可以看到生成的文件