基于MHA的MySQL高可用架构的实现

一、原理

1.MHA工作过程

（1）从宕机崩溃的master保存二进制日志事件（binlog events）;
（2）识别含有最新更新的slave;
（3）应用差异的中继日志(relay log) 到其他slave;
（4）应用从master保存的二进制日志事件(binlog events);
（5）提升一个slave为新master;
（6）使用其他的slave连接新的master进行复制。

二、准备实验MYSQL Replication环境

1.各节点都要开启二进制日志及中继日志

2.各从节点必须显示启用其read-only属性，并关闭relay_log_purge功能等

3.本实验环境共有四个节点，其角色分配如下：

node1: MHA Manager
node2: MariaDB slave
node3: MariaDB slave
node4: MariaDB master

4.各节点的/etc/hosts文件配置内容中添加：

172.17.17.173 node1.muzigan.com node1
172.17.17.174 node2.muzigan.com node2
172.17.17.175 node3.muzigan.com node3
172.17.17.176 node4.muzigan.com node4

三、MySQL主从架构实现

1.各节点都要开启二进制日志及中继日志

2.各从节点必须显示启用其read-only属性，并关闭relay_log_purge功

根据mysql高可用架构一主多从修改即可

master ---/etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
server_id=174
log_bin=/var/lib/mysql/log_bin
skip-name-resolve
relay_log=/var/lib/mysql/relay_log
[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
!includedir /etc/my.cnf.d

slave ---/etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
server_id=175
log_bin=/var/lib/mysql/log_bin
relay_log=/var/lib/mysql/relay_log
read_only=on
log_slave_updates=1
relay_log_purge=0
skip_name_resolve
[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
!includedir /etc/my.cnf.d

四、安装配置MHA

1、在所有MYSQL节点授权拥有管理权限的用户可在本地网络中有其他节点上远程访问。

当然，此时仅需要且只能在master节点运行类似如下SQL语句即可。
为了主从切换后依然整成使用，主从节点都需要运行此sql语句
grant all on *.* to 'mhaadmin'@'%' identified by 'mhapassword';

2、准备基于SSH互信通信环境：

MHA集群中的各节点彼此之间均需要基于ssh互信通信，以实现远程控制及数据管理功能。
简单起见，可在Manager节点生成密钥对儿，并设置其可远程连接本地主机后，将私钥文件及authorized_keys文件复制给余下的所有节点即可。
[root@node4 ~]#ssh-keygen -t rsa
[root@node4 ~]#ssh-copy-id  @各node

生成密钥对
此命令不要在交互式输入任何东西
ssh-keygen -t rsa
分发ssh登陆验证公钥到ssh服务端
ssh-copy-id 192.168.17.174:
manager---->master
ssh-copy-id 192.168.17.175:
manager---->slave
ssh-copy-id 192.168.17.176:
manager---->slave

要复制ssh登陆验证公钥文件和私钥文件到其他服务器，并保证copy后其他服务器可以对manager本机无密ssh连接
则需要本机的ssh登陆验证公钥文件中有自己的公钥
ssh-copy-id 192.168.17.173:
manager---->自己

谁拥有manager的ssh登陆验证公钥文件和私钥文件，就可以与已经分发出去的公钥配对，从而免密登陆--manager分发过的主机
scp /root/.ssh/id_rsa /root/.ssh/authorized_keys   172.17.17.174:/root/.ssh/
scp /root/.ssh/id_rsa /root/.ssh/authorized_keys   172.17.17.175:/root/.ssh/
scp /root/.ssh/id_rsa /root/.ssh/authorized_keys   172.17.17.176:/root/.ssh/

3、 进行MHA安装包安装

安装包资源密码：1uxa

Manager 节点
yum install mha4mysql-manager-0.56-0.el6.noarch.rpm
所有节点，包括Manager
yum install mha4mysql-node-0.56-0.el6.norch.rpm

对于manager节点
先安装
yum install mha4mysql-node-0.56-0.el6.noarch.rpm
再安装
yum install mha4mysql-manager-0.56-0.el6.noarch.rpm
可避免manager中一部分依赖关系报错

4、初始化MHA，进行配置

Manager 节点需要为每个监控的master/slave集群提供一个专用的配置文件，而所有的master/slave集群也可共享全局配置。
全局配置文件默认为/etc/masterha_default.cnf，其为可选配置。
如果仅监控一组master/slave集群，也可直接通过application的配置来提供各服务器的默认配置信息。
而每个application的配置文件路径为自定义

5、 定义MHA管理配置文件

为MHA专门创建一个管理用户，方便以后使用，在mysql的主节点上，三个节点自动同步
mkdir /etc/mha_master
vim /etc/mha_master/app1.cnf

vim    /etc/mha_master/app1.cnf
[server default]
user=mhaadmin
password=mhapassword
manager_workdir=/etc/mha_master/app1
manager_log=/etc/mha_master/app1/app1.log
remote_workdir=/var/lib/mysql
ssh_user=root
repl_user=slave
repl_password=slave_passwd
ping_interval=1
[server1]
hostname=172.17.17.174
ssh_port=22
candidate_master=1
[server2]
hostname=172.17.17.175
ssh_port=22
candidate_master=1
[server3]
hostname=172.17.17.176
ssh_port=22
candidate_master=1

6、 检测各节点间ssh互信通信配置是否Ok:

[root@node4 ~]# masterha_check_ssh -conf=/etc/mha_master/app1.cnf
输出信息最后一行类似如下信息，表示其通过检测。
#### All SSH connection tests passed successfully.
[root@node4 ~]#masterha_check_repl -conf=/etc/mha_master/app1.cnf
如果测试时会报错，可能是从节点上没有slave账号，因为这个架构，任何一个从节点，将有可能成为主节点，所以也需要创建账号。
因此，这里只要在mater节点上再次执行以下操作即可：
#grant replication slave,replication client on *.* to  slave@'%' identified by 'slave_passwd';

五、启动MHA

启动
nohup masterha_manager -conf=/etc/mha_master/app1.cnf &>/etc/mha_master/app1/app1.log &
查看master节点的状态:
[root@node4 ~]#masterha_check_status -conf=/etc/mha_master/app1.cnf
如果要停止MHA，需要使用master_stop命令。
[root@node4 ~]#masterha_stop -conf=/etc/mha_master/app1.cnf

六、测试MHA测试故障转移

(1)在master节点关闭mariadb服务,模拟主节点数据崩溃

killall -9 mysqld mysqld_safe
rm -rf /var/lib/mysql/*

(2)在manager节点查看日志：

/data/masterha/app1/manager.log
日志文件中出现如下信息，表示manager检测到172.16.252.18节点故障，而后自动执行故障转移，将172.16.252.17提升为主节点。
注意，故障转移完成后，manager将会自动停止，此时使用masterha_check_status命令检测将会遇到错误提示，如下所示：
#masterha_check_status –conf=/etc/masterha/app1.cnf

(3) 提供新的从节点以修复复制集群

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

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

masterha_check_status -conf=/etc/mha_master/app1.cnf
masterha_check_repl -conf=/etc/mha_master/app1.cnf
检查无误，再次运行，这次要记录日志
masterha_manager -conf=/etc/mha_master/app1.cnf>/etc/mha_master/manager.log 2>&1

七、新节点上线，故障转换恢复注意事项

(1)、在生产环境中，当你的主节点挂了后，一定要在从节点上做一个备份，拿着备份文件把主节点手动提升为从节点，并指明从哪一个日志文件的位置开始复制

(2)、每一次自动完成转换后，每一次的(replication health )检测不ok始终都是启动不了必须手动修复主节点，除非你改配置文件

(3)、手动修复主节点提升为从节点后，再次运行检测命令

[root@node5 ~]# masterha_check_repl --conf=/etc/mha_master/app1.cnf
提示app1 (pid:3211) is running(0:PING_OK), master:172.16.5.103

(4)、再次运行起来就恢复成功了

masterha_manager --conf=/etc/mha_master/app1.cnf