mysql实现高可用架构之MHA

mysql实现高可用之MHA

1、简介

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， 目前已支持一

主一从。

2、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 ；

3、实现过程

环境搭建

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

以上。咱们的实验已经圆满完成。