MYSQL实现高可用MHA

标签：mha

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

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

centos7.3:MariaDB master

centos7.4: MariaDB slave

centos7.5：MariaDB slave

centos7.6: MHA Manager

1 、初始主节点centos7.3 配置：

[mysqld]

server-id = 1

log-bin = master-log

relay-log = relay-log

skip_name_resolve = ON

2 、所有centos7.5和7.4 节点依赖的配置：

[mysqld]

server-id = 2 # 复制集群中的各节点的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 on *.* to 'slave@172.17.%.%' identified by 'magedu';

MariaDB [(none)]> flush privileges;

MariaDB [(none)]>show master status;

各slave 节点上：

[root@node3 ~]# mysql

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 节点授权拥有管理权限的用户可在本地网络中有其他节点上远程访问。当然，此时仅需要且只能在master 节点运行类似如下SQL 语句即可。

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

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

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

下面操作在node4 ：Manager 节点上操作：

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

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

注意：主从数据库相互之间要实现无密码登录，MHA manager 要能登录另外三台就可以了。

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 管理配置文件

为MHA 专门创建一个管理用户，方便以后使用，在mysql 的主节点上，三个节点自动同步

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.173

ssh_port=22

candidate_master=1

[server3]

hostname=172.16.5.174

ssh_port=22

candidate_master=1

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

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

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

[info]All SSH connection tests passed successfully.

检查管理的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 节点的状态:

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 命令。

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

app1 is stopped(2:NOT_RINNING).

六、测试MHA 测试故障转移

(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) 、手动修复主节点提升为从节点后，再次运行检测命令

 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

MYSQL实现高可用MHA

标签：mha

原文地址：http://blog.51cto.com/13172732/2044512