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 。对比打算提升为新的主节点之上的从节点的

是否拥有并完成操作,如果没有发给新主节点在本地应用后提升为主节点

mysql实现高可用架构之MHA_第1张图片


我们可以看出,每个复制组内部和 Manager 之间都需要ssh实现无密码互连,只有这样,在 Master 出故障时,

Manager 才能顺利的连接进去,实现主从切换功能。

2.3工作原理

mysql实现高可用架构之MHA_第2张图片

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

image.png

意思分别为

复制集群中的各节点的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;

image.png

====================================================

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;

image.png

看到有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

mysql实现高可用架构之MHA_第3张图片

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                //检测互信命令

image.png

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

[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf

mysql实现高可用架构之MHA_第4张图片


9.启动MHA

在manager节点执行操作

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

/etc/mha_master/manager.log &

image.png

会查到有个进程


启动成功后,我们来查看一下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成为了主

image.png

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;

image.png

#配置主从

[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

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