mysql实现高可用之MHA
一、简介
MHA（Master HA）是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automating
master failover （自动化主故障转移）功能。MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的
slave 节点成为新的master 节点，在此期间，MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题。
MHA 还提供了 master 节点的在线切换功能，即按需切换 master/slave 节点。 MHA 是由日本人
yoshinorim（原就职于DeNA现就职于FaceBook）开发的比较成熟的 MySQL 高可用方案。MHA 能够在30秒内实现
故障切换，并能在故障切换中，最大可能的保证数据一致性。目前淘宝也正在开发相似产品 TMHA， 目前已支持一
主一从。
二、MHA服务
2.1服务角色
MHA 服务有两种角色， MHA Manager(管理节点)和 MHA Node(数据节点)： MHA Manager： 通常单独
部署在一台独立机器上管理多个 master/slave 集群(组)，每个 master/slave 集群称作一个 application，用来管理
统筹整个集群。 MHA node： 运行在每台 MySQL 服务器上(master/slave/manager)，它通过监控具备解析和
清理 logs 功能的脚本来加快故障转移。 主要是接收管理节点所发出指令的代理，代理需要运行在每一个 mysql
节点上。简单讲 node 就是用来收集从节点服务器上所生成的 bin-log 。对比打算提升为新的主节点之上的从节点的
是否拥有并完成操作，如果没有发给新主节点在本地应用后提升为主节点
我们可以看出，每个复制组内部和 Manager 之间都需要ssh实现无密码互连，只有这样，在 Master 出故障时，
Manager 才能顺利的连接进去，实现主从切换功能。
2.3工作原理
MHA工作原理总结为以下几条： （1） 从宕机崩溃的 master 保存二进制日志事件（binlog events）； （2） 识别
含有最新更新的 slave ； （3） 应用差异的中继日志(relay log) 到其他 slave ； （4） 应用从 master 保存的二进制
日志事件(binlog events)； （5） 提升一个 slave 为新 master ；
三、实现过程
环境搭建
manager 192.168.11.151 用于监控管理
master 192.168.11.152 开启bin-log(二进制日志) relay-log(中继日志)关闭relay_log_purge
slave1 192.168.11.160 开启bin-log(二进制日志) relay-log(中继日志)关闭relay_log_purge
slave2 192.168.11.12 开启bin-log(二进制日志) relay-log(中继日志)关闭relay_log_purge
所有节点进行初始化关闭防火墙，selinux重启系统
manager hostname --static set-hostname manager
master hostname --static set-hostname master
slave1 hostname --static set-hostname slave1
slave2 hostname --static set-hostname slave2
=======================================
以下4台服务器都要做
setenforce 临时关闭selinux
systemctl stop firewalld 临时关闭防火墙
在/etc/hosts文件中写入
192.168.37.151 manager.qf.com manager
192.168.37.152 master.qf.com master
192.168.37.160 slave1.qf.com slave1
192.168.37.12 slave2.qf.com slave2
====================================
以下3台机器都要做
2.安装mariadb
yum -y install MariaDB-server MariaDB-client
3.初始化mariadb
mysql_secure_installation
4.修改master的数据库配置文件
vim /etc/my.cnf.d/server.cnf
意思分别为
复制集群中的各节点的id均必须唯一
开启二进制日志
开启中继日志
关闭名称解析（非必须）
重启mariadb服务
systemctl restart mariadb
5.配置slave节点
slave1主机
[mysqld]
server-id = 2 //复制集群中的各节点的id均必须唯一；
log-bin = master-log //开启中继日志
relay-log=relay-log //开启二进制日志
skip_name_resolve //启用只读属性
read-only=on //是否自动清空不再需要中继日志
relay-log-purge = 0 //关闭名称解析（非必须）
log-slave-updates = 1 //使得更新的数据写进二进制日志中
slave2主机
[mysqld]
server-id = 3 //复制集群中的各节点的id均必须唯一；
log-bin = master-log //开启中继日志
relay-log=relay-log //开启二进制日志
skip_name_resolve //启用只读属性
read-only=on //是否自动清空不再需要中继日志
relay-log-purge = 0 //关闭名称解析（非必须）
log-slave-updates = 1 //使得更新的数据写进二进制日志中
systemctl restart mariadb //重启mariadb服务
=======================================
配置一主多从复制架构
master节点上
mysql -uroot -p'0' //密码时前面初始化设的
MariaDB [(none)]>grant replication slave,replication client on *.* to
'slave'@'192.168.%.%' identified by 'keer';
# 备份数据导出到从库
[root@master ~]# mysqldump -uroot -p'0' --all-databases > `date +%F`-mysql-all.sql
[root@master ~]# scp *mysql-all.sql 192.168.11.160:/root
[root@master ~]# scp *mysql-all.sql 192.168.11.12:/root
[root@master ~]# mysql -uroot -p'keer'
MariaDB [(none)]> show master status;
====================================================
slave节点上 2个备都要做
#导入数据
[root@slave1 ~]# mysql -uroot -p'0' < *mysql-all.sql
[root@slave1 ~]# mysql -uroot -p'0'
MariaDB [(none)]> change master to master_host='192.168.11.152',
-> master_user='slave',
-> master_password='keer',
-> master_log_file='master-log.000002',
-> master_log_pos=483458;
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status\G;
看到有2个yes就成功了
可以测试一下，在主上新建一个库，看备上有没有同步
====================================================
5.安装配置MHA
3.2.1 在 master 上进行授权
在所有 Mysql 节点授权拥有管理权限的用户可在本地网络中有其他节点上远程访问。 当然， 此时仅需要且只能
在 master 节点运行类似如下 SQL 语句即可。
[root@master ~]# mysql -uroot -p'0'
MariaDB [(none)]> grant all on *.* to 'mhaadmin'@'192.168.%.%' identified by 'mhapass';
6.准备ssh互通环境
mananger节点
ssh-keygen //生成秘钥对
ssh-copy-id 192.168.11.151 //传公钥给自己
master节点
ssh-keygen
ssh-copy-id 192.168.11.151 ////传公钥给manager
slave1节点
ssh-keygen
ssh-copy-id 192.168.11.151 ////传公钥给manager
slave2节点
ssh-keygen
ssh-copy-id 192.168.11.151 ////传公钥给manager
然后在manager节点上
cd .ssh
scp authorized_keys 192.168.11.152:/root/.ssh/
scp authorized_keys 192.168.11.160:/root/.ssh/
scp authorized_keys 192.168.11.12:/root/.ssh/
做完之后
cat .ssh/authorized_keys
4台机器都有着4个公钥，那么4台机器就可以实现ssh无密码互通了
6.安装MHA包
四个节点都需安装： mha4mysql-node-0.56-0.el6.norch.rpm ，Manager 节点另需要安装： mha4mysqlmanager-0.56-0.el6.noarch.rpm
manager:
yum -y install mha4mysql-node.noarch
yum -y install mha4mysql-manager
master:
yum -y install mha4mysql-node.noarch
slave1
yum -y install mha4mysql-node.noarch
slave2
yum -y install mha4mysql-node.noarch
7.初始化MHA，进行配置
Manager 节点需要为每个监控的 master/slave 集群提供一个专用的配置文件，而所有的 master/slave 集群也
可共享全局配置。全局配置文件默认为 /etc/masterha_default.cnf ，其为可选配置。如果仅监控一组
master/slave 集群，也可直接通过 application 的配置来提供各服务器的默认配置信息。而每个 application 的配置
文件路径为自定义。具体操作见下一步骤。
8. 定义 MHA 管理配置文件
mkdir /etc/mha_master
vim /etc/mha_master/mha.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=keer //数据库密码
ping_interval=1 //ping间隔时长
[server1] //节点2
hostname=192.168.11.152 //节点2主机地址
ssh_port=22 //节点2的ssh端口
candidate_master=1 //将来可不可以成为master候选节点/主节点
[server2]
hostname=192.168.11.160
ssh_port=22
candidate_master=1
[server3]
hostname=192.168.11.12
ssh_port=22
candidate_master=1
8.对4个节点进行检测
1）检测各节点间 ssh 互信通信配置是否 ok 我们在 Manager 机器上输入下述命令来检测：
[root@manager ~]# masterha_check_ssh -conf=/etc/mha_master/mha.cnf //检测互信命令
2）检查管理的MySQL复制集群的连接配置参数是否OK
[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf
9.启动MHA
在manager节点执行操作
[root@manager ~]# nohup masterha_manager -conf=/etc/mha_master/mha.cnf &>
/etc/mha_master/manager.log &
会查到有个进程
启动成功后，我们来查看一下master节点的状态
[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha (pid:28109) is running(0:PING_OK), master:192.168.11.152
上面的信息中“mha (pid:28109) is running(0:PING_OK)”表示MHA服务运行OK，否则， 则会显示为类似“mha is
stopped(1:NOT_RUNNING).” 如果，我们想要停止 MHA ，则需要使用 stop 命令：
[root@manager ~]# masterha_stop -conf=/etc/mha_master/mha.cnf
======================================================
测试MHA故障转移
在 master 节点关闭 mariadb 服务,模拟主节点数据崩溃
[root@master ~]# killall5 -9 mysqld mysqld_safe
10.在manaer节点查看日志
[root@manager ~]# tail -200 /etc/mha_master/manager.log
……
Thu Nov 23 09:17:19 2017 - [info] Master failover to
192.168.37.160(192.168.37.160:3306) completed successfully
表示 manager 检测到192.168.11.152节点故障， 而后自动执行故障转移， 将192.168.11.160提升为主节点。
注意，故障转移完成后， manager将会自动停止， 此时使用 masterha_check_status 命令检测将会遇到错误
提示， 如下所示：
[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha is stopped(2:NOT_RUNNING).
可以看到master断掉之后，slave通过竞选成为主
在slave节点上，可以看到，有一个slave成为了主
11. 提供新的从节点以修复复制集群
原有 master 节点故障后，需要重新准备好一个新的 MySQL 节点。基于来自于master 节点的备份恢复数据后，
将其配置为新的 master 的从节点即可。注意，新加入的节点如果为新增节点，其 IP 地址要配置为原来 master 节点
的 IP，否则，还需要修改 mha.cnf 中相应的 ip 地址。随后再次启动 manager ，并再次检测其状态。 我们就以
刚刚关闭的那台主作为新添加的机器，来进行数据库的恢复： 原本的 slave1 已经成为了新的主机器，所以，我
们对其进行完全备份，而后把备份的数据发送到我们新添加的机器上
slave节点上：
[root@slave1 ~]# mkdir /backup
[root@slave1 ~]# mysqldump --all-database > /backup/`date +%F-%T`-mysql-all.mysql
[root@slave1 ~]# scp /backup/2019-04-25-19\:07\:05-mysql-all.mysql 192.168.11.152:/
在原master节点上进行数据恢复
启动mariadb
# 启动并初始化 mariadb
[root@master ~]# systemctl start mariadb
[root@master ~]# mysql_secure_installation
[root@master ~]#mysql < 2019-04-25-mysql-all.sql //还原数据
接下来就是配置主从，看一下现在的主的二进制日志和位置，然后进行如下设置
[root@slave1 ~]# mysql -uroot -p'keer'
MariaDB [(none)]> show master status;
#配置主从
[root@master ~]# mysql -uroot -p'0'
MariaDB [(none)]>change master to master_host='192.168.11.160', master_user='slave',
master_password='keer', master_log_file='master-log.000002', master_log_pos=483458;
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.11.160
Master_User: slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master-log.000002
Read_Master_Log_Pos: 483458
Relay_Log_File: relay-log.000002
Relay_Log_Pos: 556
Relay_Master_Log_File: master-log.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 483458
Relay_Log_Space: 859
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Slave_DDL_Groups: 0
Slave_Non_Transactional_Groups: 0
Slave_Transactional_Groups: 0
1 row in set (0.000 sec)
ERROR: No query specified
==============================================
12.新节点提供后再次执行检查操作
[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf
若没有问题，则启动 manager，注意，这次启动要记录日志：
[root@manager ~]# masterha_manager -conf=/etc/mha_master/mha.cnf >/etc/mha_master/manager.log 2>&1 &
[1] 40773
启动成功以后，我们来查看一下 master 节点的状态：
[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha (pid:9561) is running(0:PING_OK), master:192.168.37.160
我们的服务已经成功继续了。
3.7新节点上线， 故障转换恢复注意事项
1）在生产环境中， 当你的主节点挂了后， 一定要在从节点上做一个备份， 拿着备份文件把主节点手动提升为
从节点， 并指明从哪一个日志文件的位置开始复制 2）每一次自动完成转换后， 每一次的(replication health )
检测不ok始终都是启动不了必须手动修复主节点， 除非你改配置文件 3）手动修复主节点提升为从节点后， 再
次运行检测命令
[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf
mha (pid:9561) is running(0:PING_OK), master:192.168.37.160
4）再次运行起来就恢复成功了
[root@manager ~]# masterha_manager --conf=/etc/mha_master/mha.cnf
以上。我们的实验已经圆满完成。