一、简介

官方介绍:https://code.ooglesgql-master.com/p/my-ha/

  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 Manager(管理节点)和MHA Node(数据节点)。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。在MHA自动故障切换过程中,MHA试图从宕机的主服务器上保存二进制日志,最大程度的保证数据的不丢失,但这并不总是可行的。例如,如果主服务器硬件故障或无法通过ssh访问,MHA没法保存二进制日志,只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制,可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志,MHA可以将最新的二进制日志应用于其他所有的slave服务器上,因此可以保证所有节点的数据一致性。

       目前MHA主要支持一主多从的架构,要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器,一主二从,即一台充当master,一台充当备用master,另外一台充当从库slave,因为至少需要三台服务器,出于机器成本的考虑,淘宝也在该基础上进行了改造,目前淘宝TMHA已经支持一主一从。另外对于想快速搭建的可以参考:MHA快速搭建

我们自己使用其实也可以使用1主1从,但是master主机宕机后无法切换,以及无法补全binlog。master的mysqld进程crash后,还是可以切换成功,以及补全binlog的。


二、MHA 服务

1、 服务角色

  MHA 服务有两种角色, MHA Manager(管理节点)和 MHA Node(数据节点):

MHA Manager:

  通常单独部署在一台独立机器上管理多个 master/slave 集群(组),每个 master/slave 集群称作一个 application,用来管理统筹整个集群。

MHA node:

  运行在每台 MySQL 服务器上(master/slave/manager),它**通过监控具备解析和清理 logs 功能的脚本来加快故障转移。

  主要是接收管理节点所发出指令的代理,代理需要运行在每一个 mysql 节点上。简单讲 node 就是用来收集从节点服务器上所生成的 bin-log 。对比打算提升为新的主节点之上的从节点的是否拥有并完成操作,如果没有发给新主节点在本地应用后提升为主节点。


2、提供的工具

MHA会提供诸多工具程序, 其常见的如下所示:

Manager节点:

  `masterha_check_ssh`:MHA 依赖的 ssh 环境监测工具;

  `masterha_check_repl`:MYSQL 复制环境检测工具;

  `masterga_manager`:MHA 服务主程序;

  `masterha_check_status`:MHA 运行状态探测工具;

  `masterha_master_monitor`:MYSQL master 节点可用性监测工具;

  `masterha_master_swith:master`:节点切换工具;

  `masterha_conf_host`:添加或删除配置的节点;

  `masterha_stop`:关闭 MHA 服务的工具。

Node节点:(这些工具通常由MHA Manager的脚本触发,无需人为操作)

  `save_binary_logs`:保存和复制 master 的二进制日志;

  `apply_diff_relay_logs`:识别差异的中继日志事件并应用于其他 slave;

  `purge_relay_logs`:清除中继日志(不会阻塞 SQL 线程);

  自定义扩展:

  `secondary_check_script`:通过多条网络路由检测master的可用性;

  `master_ip_failover_script`:更新application使用的masterip;

  `report_script`:发送报告;

  `init_conf_load_script`:加载初始配置参数;

  `master_ip_online_change_script`;更新master节点ip地址。


3、工作原理


MHA工作原理总结为以下几条:

(1) 从宕机崩溃的 master 保存二进制日志事件(binlog events);

(2) 识别含有最新更新的 slave ;

(3) 应用差异的中继日志(relay log) 到其他 slave ;

(4) 应用从 master 保存的二进制日志事件(binlog events);

(5) 提升一个 slave 为新 master ;


三、实现步骤


 1、相关配置

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

  本实验环境共有四个节点, 其角色分配如下(实验机器均为centos 7):


机器名称 IP 角色 备注
manager 192.168.11.131 manager 控制器 用于监控管理
master 192.168.11.128 数据库主服务器 开启bin-log relay-log 关闭relay-log-purge
slave1 192.168.11.130 数据库从服务器 开启bin-log relay-log 关闭relay-log-purge
slave2 192.168.11.132 数据库从服务器 开启bin-log relay-log 关闭relay-log-purge


[root@node131 ~]# hostnamectl  --static  set-hostname  manager

[root@manager ~]# systemctl  status  firewalld

[root@manager ~]# systemctl  stop  firewalld

[root@manager ~]# systemctl  disable  firewalld

[root@manager ~]# vim  /etc/selinux/config

修改 SELINUX=disabled

[root@manager ~]# getenforce


[root@node128 ~]# hostnamectl  --static  set-hostname  master

[root@master ~]# systemctl  status  firewalld

[root@master ~]# systemctl  stop  firewalld

[root@master ~]# systemctl  disable  firewalld

[root@master ~]# vim  /etc/selinux/config

修改 SELINUX=disabled


[root@node130 ~]# hostnamectl  --static  set-hostname  slave1

[root@slave1 ~]# systemctl  status  firewalld

[root@slave1 ~]# systemctl  stop  firewalld

[root@slave1 ~]# systemctl  disable  firewalld

[root@slave1~]# vim  /etc/selinux/config

修改 SELINUX=disabled


[root@node132 ~]# hostnamectl  --static  set-hostname  slave2

[root@slave2 ~]# systemctl  status  firewalld

[root@slave2 ~]# systemctl  stop  firewalld

[root@slave2 ~]# systemctl  disable  firewalld

[root@slave2 ~]# vim  /etc/selinux/config

修改 SELINUX=disabled


为了方便我们后期的操作,我们在节点的/etc/hosts文件配置内容中添加如下内容:

image.png

2、在master、slave1、slave2上都安装mariadb

(1)、安装

[root@master ~]# yum -y install mariadb-server mariadb-client

(2)、启动mariadb

systemctl  restart  mariadb

(3)、初始化mariadb

[root@master ~]# mysql_secure_installation


3、初始主节点master的配置

备份:cp  /etc/my.cnf.d/server.cnf{,.bak}

[root@master ~]# vim /etc/my.cnf.d/server.cnf

    [mysqld]

    server-id = 0               //复制集群中的各节点的id均必须唯一

    log-bin = master-log        //开启二进制日志

    relay-log = relay-log       //开启中继日志

    skip_name_resolve           //关闭名称解析(非必须)

[root@master ~]# systemctl restart mariadb


4、所有slave节点的配置

备份:cp  /etc/my.cnf{,.bak}

[root@slave1 ~]# vim /etc/my.cnf

    [mysqld]

    server-id = 1               //复制集群中的各节点的id均必须唯一;

    relay-log = relay-log       //开启中继日志

    log-bin = master-log        //开启二进制日志

    read_only = ON              //启用只读属性

    relay_log_purge = 0         //是否自动清空不再需要中继日志

    skip_name_resolve           //关闭名称解析(非必须)

    log_slave_updates = 1       //使得更新的数据写进二进制日志中

[root@slave1 ~]# systemctl restart mariadb

备份:cp  /etc/my.cnf{,.bak}

[root@slave2 ~]# vim /etc/my.cnf

    [mysqld]

    server-id = 2               //复制集群中的各节点的id均必须唯一;

    relay-log = relay-log       //开启中继日志

    log-bin = master-log        //开启二进制日志

    read_only = ON              //启用只读属性

    relay_log_purge = 0         //是否自动清空不再需要中继日志

    skip_name_resolve           //关闭名称解析(非必须)

    log_slave_updates = 1       

[root@slave2 ~]# systemctl restart mariadb


5、配置一主多从复制架构

master节点上:

授权同步数据账号

[root@master ~]# mysql -uroot -p'keer'

MariaDB [(none)]>grant replication slave,replication client on *.* to 'slave'@'192.168.%.%' identified by 'keer';

备份数据导出到slave1、slave2从库

[root@master ~]# mysqldump -uroot -p'keer' --all-databases > `date +%F`-mysql-all.sql

[root@master ~]# scp *mysql-all.sql  192.168.11.13:/root

[root@master ~]# mysql -uroot -p'keer'

MariaDB [(none)]> show master status;

MySQL实现高可用之MHA_第1张图片


slave节点上:(slave1\2都要操作)

导入数据

[root@slave1 ~]# mysql -uroot -p'keer' < *mysql-all.sql

[root@slave1 ~]# mysql -uroot -p'keer'

MariaDB [(none)]> help change master to;

MySQL实现高可用之MHA_第2张图片

MariaDB [(none)]> CHANGE MASTER TO

    ->   MASTER_HOST='192.168.11.128',

    ->   MASTER_USER='slave',

    ->   MASTER_PASSWORD='keer',

    ->   MASTER_PORT=3306,

    ->   MASTER_LOG_FILE='mysql-log.000001',

    ->   MASTER_LOG_POS=329,

    ->   MASTER_CONNECT_RETRY=10;

MariaDB [(none)]> start slave;

MariaDB [(none)]> show slave status\G;

slave1、slave2上查询的结果如下为成功

MySQL实现高可用之MHA_第3张图片


6、在master上授权

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

[root@master ~]# mysql -uroot -p'keer'

MariaDB [(none)]> grant all on *.* to 'mhaadmin'@'192.168.%.%' identified by 'mhapass';

MariaDB [(none)]>\q


7、准备ssh多机通信

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

manager节点:

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

[root@manager ~]# ssh-copy-id 192.168.11.131

MySQL实现高可用之MHA_第4张图片

master、slave1、slave2执行以下操作:

MySQL实现高可用之MHA_第5张图片[root@manager ~]# cd .ssh/

[root@manager .ssh]# ls

authorized_keys  id_rsa  id_rsa.pub  known_hosts

[root@manager .ssh]# cat authorized_keys 


四台机器的公钥都已经在authorized_keys这个文件中了,接着,我们只需要把这个文件发送至另外三台机器,这四台机器就可以实现 ssh 无密码互通了:

[root@manager .ssh]# scp authorized_keys 192.168.11.128:/root/.ssh/

[root@manager .ssh]# scp authorized_keys 192.168.11.130:/root/.ssh/

[root@manager .ssh]# scp authorized_keys 192.168.11.132:/root/.ssh/

测试一下是否能互通:

ssh 192.168.11.128

退出:exit

MySQL实现高可用之MHA_第6张图片

8、安装MHA

四个节点都需安装:mha4mysql-node-0.56-0.el6.norch.rpm

Manager 节点另需要安装:mha4mysql-manager-0.56-0.el6.noarch.rpm

[root@manager ~]# yum install -y mha4mysql-node-0.56-0.el6.noarch.rpm 

[root@manager ~]# yum install -y mha4mysql-manager-0.56-0.el6.noarch.rpm 

注:其余机器也分别进行安装,就不一 一举例了。


manager节点:

[root@manager ~]# mkdir /etc/mha_master

[root@manager ~]# vim /etc/mha_master/mha.cnf


配置文件内容如下:

[server default]                                                          //适用于server1,2个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]                                                                    //节点2

hostname=192.168.11.13                                         //节点2主机地址

ssh_port=22                                                              //节点2的ssh端口

candidate_master=1                                                 //将来可不可以成为master候选节点/主节点

[server2]

hostname=192.168.11.14

ssh_port=22

candidate_master=1

对3个节点进行测试

1)检测各节点间 ssh 互信通信配置是否 ok

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

MySQL实现高可用之MHA_第7张图片

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

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


[error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln301] Got MySQL error when connecting 192.168.11.130(192.168.11.130:3306):1045:Access denied for user 'mhaadmin'@'192.168.11.128'(using password: YES),but this is not a MySQL crash.Check MySQL server settings.

image.png

  我们发现检测失败,这可能是因为从节点上没有账号,因为这个架构,任何一个从节点, 将有可能成为主节点, 所以也需要创建账号。

  因此,我们需要在master节点上再次执行以下操作:

[root@master ~]# mysql -uroot -p'keer'

MariaDB [(none)]> grant  replication slave,replication client on *.* to 'slave'@'192.168.%.%' identified by 'keer';

MariaDB [(none)]> flush privileges;

MariaDB [(none)]> exit

执行完这段操作之后,我们再次运行检测命令:

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

MySQL Replication Health is OK!


启动MHA

在manager节点上执行以下命令来启动MHA:

[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

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


9、测试MHA故障转移

在master节点关闭mariadb服务,模拟主节点数据崩溃


[root@master ~]# yum -y install psmisc

[root@master ~]# killall mysqld mysqld_safe

在manager节点查看日志

tail  /etc/mha_master/manager.log

Thu May  10 21:12:50  2019 - [info] Master failover to 192.168.11.130(192.168.11.130:3306) completed successfully.

表示 manager 检测到192.168.11.128节点故障, 而后自动执行故障转移, 将192.168.11.130提升为主节点。

注意,故障转移完成后, manager将会自动停止, 此时使用 masterha_check_status 命令检测将会遇到错误提示, 如下所示:[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf

mha is stopped(2:NOT_RUNNING).


提供新的从节点以修复复制集群

  原有 master 节点故障后,需要重新准备好一个新的 MySQL 节点。基于来自于master 节点的备份恢复数据后,将其配置为新的 master 的从节点即可。注意,新加入的节点如果为新增节点,其 IP 地址要配置为原来 master 节点的 IP,否则,还需要修改 mha.cnf 中相应的 ip 地址。随后再次启动 manager ,并再次检测其状态。

  我们就以刚刚关闭的那台主作为新添加的机器,来进行数据库的恢复:

  原本的 slave1 已经成为了新的主机器,所以,我们对其进行完全备份,而后把备份的数据发送到我们新添加的机器上:

[root@slave1 ~]# mkdir /backup

[root@slave1 ~]# mysqldump --all-database > /backup/`date +%F-%T`-myql-all.sql

[root@slave1 ~]# scp /backup/2019-05-10-21\:20\:09-mysql-all.sql 192.168.11.131:/root/

  然后在 原master 节点上进行数据恢复:

# 启动并初始化 mariadb

[root@master ~]# systemctl start mariadb

[root@master ~]# mysql_secure_installation

还原数据

[root@master ~]# mysql < 2019-05-10-21\:20\:09-mysql-all.sql

  接下来就是配置主从。照例查看一下现在的主的二进制日志和位置,然后就进行如下设置:

查看主服务器信息

[root@slave1 ~]# mysql -uroot -p'keer'

MariaDB [(none)]> show master status;

# 配置主从

[root@master ~]# mysql -uroot -p'keer'

MariaDB [(none)]> show master status;

MariaDB [(none)]> change master to master_host='192.168.11.130',  master_user='slave',  master_password='keer', master_log_file='mysql-bin.000003', master_log_pos=625;

MariaDB [(none)]> start slave;

MariaDB [(none)]> show slave status\G;

Slave_IO_State: Waiting for master to send event

                  Master_Host: 192.168.11.130

                  Master_User: slave

                   Master_Port: 3306

               Connect_Retry: 60

             Master_Log_File: mysql-bin.000006

   Read_Master_Log_Pos:625

                Relay_Log_File: mysql-relay-bin.000002

                Relay_Log_Pos: 529

    Relay_Master_Log_File: mysql-bin.000006

           Slave_IO_Running: Yes

         Slave_SQL_Running: Yes


到此主从已经配置OK了


新节点提供后再次执行检查操作

再次检测状态:

[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 &

启动成功以后,查看一下 master 节点的状态:

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

mha (pid:9561) is running(0:PING_OK), master:192.168.11.130


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


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

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

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