MySQL高可用架构之MHA实验

一、准备实验MYSQL Replication环境：

MHA对MYSQL复制环境有特殊要求，例如各节点都要开启二进制日志及中继日志，各从节点必须显示启用其read-only属性，并关闭relay_log_purge功能等，这里对配置做事先说明。

注意：开始试验之前，同步时间，关闭iptables，关闭selinux；

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

node1：MariaDB master

node2：MariaDB slave

node3：MariaDB slave

node4：MHA Manager

1、初始主节点master配置，编辑/etc/my.cnf文件：

node1节点：

[mysqld]

server-id = 1

log-bin = master-log

relay-log = relay-log

skip_name_resolve = ON # == skip_name_resolve

2、slave节点依赖的配置：

node2节点：

[mysqld]

server-id = 2 #复制集群中的各节点的id均必须唯一；

relay-log = relay-log

log-bin = master-log

read_only = ON

relay_log_purge = 0 #是否自动清空不再需要中继日志

skip_name_resolve = ON

node3节点：

[mysqld]

server-id = 3 #复制集群中的各节点的id均必须唯一；

relay-log = relay-log

log-bin = master-log

read_only = ON

relay_log_purge = 0 #是否自动清空不再需要中继日志

skip_name_resolve = ON

3、按上述要求分别配置好主从节点之后，按MYSQL复制配置架构的配置方式将其配置完成，并启动master节点和各slave节点，以及为各slave节点启动其IO和SQL线程，确保主从复制运行无误。操作如下：

master节点上：

MariaDB [(none)]> GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'slave@172.17.%.%' IDENTIFIED BY 'magedu';

MariaDB [(none)]> FLUSH PRIVILEGES;

MariaDB [(none)]> SHOW MASTER STATUS;

slave节点上，注意所有的slave节点都要执行这样的操作：

[root@node3 ~]# mysql -uroot

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='172.16.252.18′,MASTER_USER='repluser',MASTER_PASSWORD='replpass',MASTER_LOG_FILE='master-log.000003',MASTER_LOG_POS=498;

MariaDB [(none)]> START SLAVE;

MariaDB [(none)]> SHOW SLAVE STATUS\G;

二、安装配置MHA

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

在node1、node2、node3执行：：

mysql> GRANT ALL ON *.* TO 'mhaadmin'@'172.17.%.%' IDENTIFIED BY 'mhapass';

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

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

在node1、node2、node3、node4执行：

[root@node4 ~]# ssh-keygen -t rsa

[root@node4 ~]# ssh-copy-id -i .ssh/id_rsa.pub root@node4

注意：要将所有节点的ssh打通。

3、 进行MHA安装包安装：

Manager 节点： # yum install mha4mysql-manager-0.56-0.el6.noarch.rpm

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

4、初始化MHA，进行配置：

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

5、 定义MHA管理配置文件：

只在node4节点上操作：

mkdir /etc/mha_master

vim /etc/mha_master/app1.cnf

配置文件内容如下：

[server default] //适用于server1,2,3个server的配置

user=mhaadmin //mha管理用户

password=mhapass //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=slave //数据库用户名

repl_password=magedu //数据库密码

ping_interval=1 // ping间隔时长

[server1] //节点1

hostname=172.16.5.102 //节点1主机地址

ssh_port=22 //节点1的ssh端口

candidate_master=1 // 将来可不可以成为master候选节点/主节点

[server2]

hostname=172.16.5.103

ssh_port=22

candidate_master=1

[server3]

hostname=172.16.5.104

ssh_port=22

candidate_master=1

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

只在node4执行：

[root@node4 ~]# masterha_check_ssh -conf=/etc/mha_master/app1.cnf

输出信息最后一行类似如下信息，表示其通过检测：

检查管理的MySQL复制集群的连接配置参数是否OK：

[root@node4 ~]# masterha_check_repl -conf=/etc/mha_master/app1.cnf

输出信息最后一行类似如下信息，表示其通过检测：

如果测试时会报错，可能是从节点上没有账号，因为这个架构，任何一个从节点，将有可能

成为主节点，所以也需要创建账号。因此，这里只要在mater节点上再次执行以下操作即可：

MariaDB [(none)]> GRANT REPLICATION SLAVE,REPLICATION CLIENT ON

*.* TO 'slave@172.17.%.%' IDENTIFIED BY 'magedu';

MariaDB [(none)]> FLUSH PRIVILEGES;

Manager节点上再次运行，就显示Ok了。

三、启动MHA

[root@node4 ~]# nohup masterha_manager -conf=/etc/mha_master/app1.cnf &> /etc/mha_master/manager.log &

# 启动成功后，可用过如下命令来查看master节点的状态：

[root@node4 ~]# masterha_check_status -conf=/etc/mha_master/app1.cnf

app1 (pid:4978)is running(0:PING_OK),master:172.16.252.18

上面的信息中“app1 (pid:4978)is running(0:PING_OK)”表示MHA服务运行OK，否则，则会显示为类似“app1 is stopped(1:NOT_RUNNINg).”

如果要停止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/mha_master/app1.cnf

app1 is stopped(2:NOT_RINNING).

(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)、再次运行起来就恢复成功了：

[root@node5 ~]# masterha_manager --conf=/etc/mha_master/app1.cnf