什么是MHA?

  首先在我们进行架构部署前,简单地了解一下什么是MHA?
  MHA(Master HA)是一款开源的 MySQL 的高可用程序,它为 MySQL 主从复制架构提供 了 automating master failover 功能。MHA 在监控到 master 节点故障时,会提升其中拥有最新数据的 slave 节点成为新的 master 节点,在此期间,MHA 会通过于其它从节点获取额外信息来避免 一致性方面的问题。MHA 还提供了 master 节点的在线切换功能,即按需切换 master/slave 节点。
   MHA 服务有两种角色,MHA Manager(管理节点)和 MHA Node(数据节点):
    (1)MHA Manager: 通常单独部署在一台独立机器上管理多个 master/slave 集群(组),每个 master/slave 集群称作一个 application,用来管理统筹整个集群。
    (2)MHA node: 运行在每台 MySQL 服务器上(master/slave/manager),它通过监控具备解析 和清理 logs 功能的脚本来加快故障转移。 主要是接收管理节点所发出指令的代理,代理需要运行在每一个mysql节点上 。 简单讲node就是用来收集从节点服务器上所生成的bin-log。对比打算提升为 新的主节点之上的从节点的是否拥有并完成操作,如果没有发给新主节点在本 地应用后提升为主节点。

MHA的工作原理:

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

实验

    在了解了上面的概念后我们就可以开始来实际操作了。
一、环境准备:
   MHA对MYSQL复制环境有特殊要求,各节点都要开启二进制日志及中继日志 ,各从节点必须显示启用其read-only属性,并关闭relay_log_purge功能等,这里 对配置做事先说明。
   本实验环境共有四个节点,其角色分配如下:
      node1:MariaDB master
      node2: MariaDB slave
      node3: MariaDB slave
      node4: MHA Manager
MySQL高可用架构之MHA_第1张图片 
             MHA架构图
1、主节点master配置:

[mysqld] 
server-id = 1 
log-bin = master-log 
relay-log = relay-log 
skip_name_resolve = ON

2、所有slave节点的配置

[mysqld] 
server-id=2
relay-log=relay-bin
log-bin=slave-bin
read-only=on
relay-log-purge=0 #是否自动清空不再需要中继日志
skip_name_resolve = on
log_slave_updates = 1 #使得更新的数据写进二进制日志中 

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

MariaDB [(none)]> grant replication slave,replication client on *.* to slave@'172.17.%.%' identified by '111111';
MariaDB [(none)]> show master status;

Slave 节点上:

MariaDB [(none)]> change master to master_host='172.17.253.210', master_user='slave', master_password='111111', master_log_file='master-bin.000001', master_log_pos=414;
MariaDB [(none)]>start slave;启动复制线程。
MariaDB [(none)]>show slave status\G;

二、安装配置MHA
1、在所有MYSQL节点授权拥有管理权限的用户可在本地网络中有其他节点上远程访问。当 然,此时仅需要且只能在master节点运行类似如下SQL语句即可。
grant all on *.* to mhaadmin@'172.17.%.%' identified by '111111';
2、准备基于SSH互信通信环境: MHA集群中的各节点彼此之间均需要基于ssh互信通信,以实现远程控制及数据管理功能。 简单起见,可在Manager节点生成密钥对儿,并设置其可远程连接本地主机后,将私钥文件 及authorized_keys文件复制给余下的所有节点即可。(其它各节点按照同样的步骤,以保证四个节点互相之间能免密登录。)

ssh-copy-id -i .ssh/id_rsa.pub [email protected]
ssh-copy-id -i .ssh/id_rsa.pub [email protected]
ssh-copy-id -i .ssh/id_rsa.pub [email protected]
ssh-copy-id -i .ssh/id_rsa.pub [email protected]

3、进行MHA安装包安装

Manager 节点: #yum localinstall mha4mysql-manager-0.56-0.el6.noarch.rpm 
所有节点,包括Manager: #yum localinstall mha4mysql-node-0.56-0.el6.norch.rpm

4、定义MHA管理配置文件 为MHA专门创建一个管理用户,方便以后使用,在mysql的主节点上,三个节点自动同步

mkdir /etc/masterha/app1.cnf
[root@manager masterha]#vim /etc/masterha/app1.cnf
[server default] //适用于server1,2,3个server的配置 
user=mhaadmin //mha管理用户 
password=111111 //mha管理密码 
manager_workdir=/etc/masterha/app1
manager_log=/etc/masterha/manager.log  // mha_master自己的日志文件 
remote_workdir=/etc/masterha/mha  //每个远程主机的工作目录在何处 
ssh_user=root // 基于ssh的密钥认证 
repl_user=slave//数据库用户名 
repl_password=111111 //数据库密码 
ping_interval=1 // ping间隔时长 

[server1]  
hostname=172.17.253.210 
ssh_port=22  
candidate_master=1  
port=3306
[server2] 
hostname=172.17.254.222  
ssh_port=22  
candidate_master=1 
port=3306
[server3] 
hostname=172.17.254.224 
ssh_port=22 
candidate_master=1
port=3306

配置文件中注释在执行时要去掉,否则在下步检查ssh时会出错。
6、检查各节点ssh是否能够通信
[root@manager ~]#masterha_check_ssh --conf=/etc/masterha/app1.cnf
检查管理的MySQL复制集群的连接配置参数是否OK:
[root@manager ~]#masterha_check_repl --conf=/etc/masterha/app1.cnf
三、启动MHA

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

检查状态是否已启动:

[root@manager ~]#masterha_check_status --conf=/etc/masterha/app1.cnf 
app1 (pid:72494) is running(0:PING_OK), master:172.17.253.210
上面的信息中“app1 (pid:4978)is running(0:PING_OK)”表示MHA服务运行OK, 否则,则会显示为类似“app1 is stopped(1:NOT_RUNNINg).”
如果要停止MHA,需要使用master_stop命令:
[root@manager ~]#masterha_stop -conf=/etc/mastermha/app1.cnf

四、测试MHA故障转移
(1)在master节点关闭mariadb服务,模拟主节点数据崩溃
[root@manager ~]#systemctl stop mariadb
(2)在manager节点查看日志:
/etc/masterha/manager.log,日志文件中出现如下信息,表示manager检测到172.17.253.210节点故障,而后自动执行故障转移,将172.17.254.222提升为主节点。注意,故障转移完成后,manager将会自动停止,此时使用 masterha_check_status命令检测将会遇到错误提示,如下所示:

 [root@manager ~]#masterha_check_status –conf=/etc/masterha/app1.cnf 
app1 is stopped(2:NOT_RINNING).

(3)提供新的从节点以修复复制集群 原有 master 节点故障后,需要重新准备好一个新的 MySQL 节点。基于来自于 master 节点的备份恢复数据后,将其配置为新的 master 的从节点即可。注意, 新加入的节点如果为新增节点,其 IP 地址要配置为原来 master 节点的 IP,否则 ,还需要修改 app1.cnf 中相应的 ip 地址。随后再次启动 manager,并再次检测 其状态。修改/etc/masterha/app1.cnf的文件为(即把原来的server2提升为server1主节点,把candidate_master=1删除):

[server default] //适用于server1,2,3个server的配置 
user=mhaadmin //mha管理用户 
password=111111 //mha管理密码 
manager_workdir=/etc/masterha/app1
manager_log=/etc/masterha/manager.log  // mha_master自己的日志文件 
remote_workdir=/etc/masterha/mha  //每个远程主机的工作目录在何处 
ssh_user=root // 基于ssh的密钥认证 
repl_user=slave//数据库用户名 
repl_password=111111 //数据库密码 
ping_interval=1 // ping间隔时长 
[server1]
hostname=172.17.254.222
ssh_port=22
port=3306
[server2]
hostname=172.17.254.224
ssh_port=22
candidate_master=1
port=3306

此时再检测状态,并且主节点已经切换:

[root@manager ~]#masterha_check_status --conf=/etc/masterha/app1.cnf 
app1 (pid:73791) is running(0:PING_OK), master:172.17.254.222
[root@manager ~]#masterha_check_repl --conf=/etc/masterha/app1.cnf       
Thu Nov 23 09:18:31 2017 - [info] Reading default configuration from /etc/masterha_default.cnf..
Thu Nov 23 09:18:31 2017 - [info] Reading application default configuration from /etc/masterha/app1.cnf..
Thu Nov 23 09:18:31 2017 - [info] Reading server configuration from /etc/masterha/app1.cnf..
Thu Nov 23 09:18:31 2017 - [info] MHA::MasterMonitor version 0.56.
Thu Nov 23 09:18:32 2017 - [info] GTID failover mode = 0
Thu Nov 23 09:18:32 2017 - [info] Dead Servers:
Thu Nov 23 09:18:32 2017 - [info] Alive Servers:
Thu Nov 23 09:18:32 2017 - [info]   172.17.254.222(172.17.254.222:3306)
Thu Nov 23 09:18:32 2017 - [info]   172.17.254.224(172.17.254.224:3306)
Thu Nov 23 09:18:32 2017 - [info] Alive Slaves:
Thu Nov 23 09:18:32 2017 - [info]   172.17.254.224(172.17.254.224:3306)  Version=5.5.52-MariaDB (oldest major version between slaves) log-bin:enabled
Thu Nov 23 09:18:32 2017 - [info]     Replicating from 172.17.254.222(172.17.254.222:3306)
Thu Nov 23 09:18:32 2017 - [info]     Primary candidate for the new Master (candidate_master is set)
Thu Nov 23 09:18:32 2017 - [info] Current Alive Master: 172.17.254.222(172.17.254.222:3306)
Thu Nov 23 09:18:32 2017 - [info] Checking slave configurations..
Thu Nov 23 09:18:32 2017 - [warning]  relay_log_purge=0 is not set on slave 172.17.254.224(172.17.254.224:3306).
Thu Nov 23 09:18:32 2017 - [info] Checking replication filtering settings..
Thu Nov 23 09:18:32 2017 - [info]  binlog_do_db= , binlog_ignore_db= 
Thu Nov 23 09:18:32 2017 - [info]  Replication filtering check ok.
Thu Nov 23 09:18:32 2017 - [info] GTID (with auto-pos) is not supported
Thu Nov 23 09:18:32 2017 - [info] Starting SSH connection tests..
Thu Nov 23 09:18:34 2017 - [info] All SSH connection tests passed successfully.
Thu Nov 23 09:18:34 2017 - [info] Checking MHA Node version..
Thu Nov 23 09:18:34 2017 - [info]  Version check ok.
Thu Nov 23 09:18:34 2017 - [info] Checking SSH publickey authentication settings on the current master..
Thu Nov 23 09:18:35 2017 - [info] HealthCheck: SSH to 172.17.254.222 is reachable.
Thu Nov 23 09:18:35 2017 - [info] Master MHA Node version is 0.56.
Thu Nov 23 09:18:35 2017 - [info] Checking recovery script configurations on 172.17.254.222(172.17.254.222:3306)..
Thu Nov 23 09:18:35 2017 - [info]   Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/var/lib/mysql,/var/log/mysql --output_file=/etc/masterha/mha/save_binary_logs_test --manager_version=0.56 --start_file=slave-bin.000001 
Thu Nov 23 09:18:35 2017 - [info]   Connecting to [email protected](172.17.254.222:22).. 
  Creating /etc/masterha/mha if not exists..    ok.
  Checking output directory is accessible or not..
   ok.
  Binlog found at /var/lib/mysql, up to slave-bin.000001
Thu Nov 23 09:18:36 2017 - [info] Binlog setting check done.
Thu Nov 23 09:18:36 2017 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers..
Thu Nov 23 09:18:36 2017 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user='mhaadmin' --slave_host=172.17.254.224 --slave_ip=172.17.254.224 --slave_port=3306 --workdir=/etc/masterha/mha --target_version=5.5.52-MariaDB --manager_version=0.56 --relay_log_info=/var/lib/mysql/relay-log.info  --relay_dir=/var/lib/mysql/  --slave_pass=xxx
Thu Nov 23 09:18:36 2017 - [info]   Connecting to [email protected](172.17.254.224:22).. 
  Checking slave recovery environment settings..
    Opening /var/lib/mysql/relay-log.info ... ok.
    Relay log found at /var/lib/mysql, up to relay-bin.000002
    Temporary relay log file is /var/lib/mysql/relay-bin.000002
    Testing mysql connection and privileges.. done.
    Testing mysqlbinlog output.. done.
    Cleaning up test file(s).. done.
Thu Nov 23 09:18:36 2017 - [info] Slaves settings check done.
Thu Nov 23 09:18:36 2017 - [info] 
172.17.254.222(172.17.254.222:3306) (current master)
 +--172.17.254.224(172.17.254.224:3306)

Thu Nov 23 09:18:36 2017 - [info] Checking replication health on 172.17.254.224..
Thu Nov 23 09:18:36 2017 - [info]  ok.
Thu Nov 23 09:18:36 2017 - [warning] master_ip_failover_script is not defined.
Thu Nov 23 09:18:36 2017 - [warning] shutdown_script is not defined.
Thu Nov 23 09:18:36 2017 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.
检查无误再次运行:
[root@manager ~]# masterha_manager 
--conf=/etc/masterha/app1.cnf&>/etc/masterha/manager.log &     
[2] 74401

新节点上线,故障转换恢复注意事项:

(1)、在生产环境中,当你的主节点挂了后,一定要在从节点上做一个备份,拿着备 份文件把主节点手动提升为从节点,并指明从哪一个日志文件的位置开始复制
(2)、每一次自动完成转换后,每一次的(replication health )检测不ok始终都是启 动不了必须手动修复主节点,除非你改配置文件
(3)、手动修复主节点提升为从节点后,再次运行检测命令

[root@manager ~]#masterha_check_repl --conf=/etc/masterha/app1.cnf 
..............
MySQL Replication Health is OK.

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

[root@manager ~]#masterha_manager --conf=/etc/masterha/app1.cnf
[root@manager ~]#masterha_check_status --conf=/etc/masterha/app1.cnf 
app1 (pid:73791) is running(0:PING_OK), master:172.17.254.222