MySQL high availability construction solution (MHA)

Sometimes the blog content will change. The first blog is the latest, and other blog addresses may not be synchronized. Check it carefully.https://blog.zysicyj.top

First blog address

Original address


Introduction to MHA architecture

MHA is the abbreviation of Master High Availability. It is a relatively mature solution for MySQL high availability. Its core is a set of scripts written in perl language. It is an excellent set of failover and master solutions in the MySQL high availability environment. Highly available software from Boost. During the MySQL failover process, MHA can automatically complete the database failover operation within 0 to 30 seconds, and can ensure data consistency to the greatest extent to achieve true high availability.

The MHA-based architecture does not require the establishment of master-master replication like MMM. It only requires the establishment of a basic master-slave replication architecture. Because MHA selects one slave library from multiple slave libraries as the new master library when the main library hangs up. Each node in the MHA cluster needs to sshcommunicate with each other based on mutual trust to achieve remote control and data management functions.

"What functions does MHA provide:"

  • Can monitor whether the Master node is available
  • When the Master is unavailable, a new Master can be elected among multiple Slaves.
  • Provides master-slave switching and failover functions. MHA will try to save the binlog on the downed Master to ensure that transactions are not lost to the greatest extent. However, if the server where the Master is located is no longer accessible, or there is a problem at the hardware level, the binlog cannot be saved successfully.
  • MHA can be combined with semi-synchronous replication to avoid data inconsistency between slave libraries.
  • Supports MySQL's two replication methods based on GTID and log point.

"MHA failover process:"

  1. Try to ssh log in to the crashed Master node to save binary log events (binlog events);
  2. Identify the slave with the latest update from multiple slaves and use it as an alternative master;
  3. 然后基于该Slave同步差异的中继日志(relaylog)到其他的Slave上;
  4. 接着同步从原Master上保存的二进制日志事件(binlog events);
  5. 将备选的Master提升为新的Master;
  6. 使其他的Slave连接新的Master进行复制;
  7. 在新的Master启动vip地址,保证前端请求可以发送到新的Master。

「MHA的架构图如下:」
alt


动手搭建MHA架构

「本文中所使用的机器说明:」

名称 IP 角色
master 192.168.190.151 主库
slave-01 192.168.190.152 从库
slave-02 192.168.190.154 从库
manager 192.168.190.153 集群管理节点(MHA)

「环境版本说明:」

  • 操作系统版本:CentOS 7
  • MySQL版本:8.0.19
  • MHA版本:0.58

「另外的说明:」

  • 会来了解MMM架构的小伙伴们想必都已经掌握了MySQL的安装方式,而且介绍 MySQL的安装 也有很多文章,所以本文为了减少不必要的篇幅就不演示MySQL的安装了,文中所用到的机器都已经提前安装好了MySQL。

配置主从节点的配置文件

1、在所有主从节点上使用如下语句创建用于主从复制的MySQL用户,因为每个从库都有可能会被选举为主库,所以都需要拥有用于复制的用户:

create user 'repl'@'%' identified with mysql_native_password by 'Abc_123456';
grant replication slave on *.* to 'repl'@'%';
flush privileges;

2、然后修改master节点上的MySQL配置文件:

[root@master ~]# vim /etc/my.cnf
[mysqld]
# 设置当前节点的id
server_id=101
# 开启binlog,并指定binlog文件的名称
log_bin=mysql_bin
# 开启relay_log,并指定relay_log文件的名称
relay_log=relay_bin
# 将relaylog的同步内容记录到binlog中
log_slave_updates=on
# 开启GTID复制模式
gtid_mode=ON
enforce_gtid_consistency=1

3、在slave-01的配置文件中也是添加一样配置,只不过server_id不一样:

[root@slave-01 ~]# vim /etc/my.cnf
[mysqld]
server_id=102
log_bin=mysql_bin
relay_log=relay_bin
log_slave_updates=on
gtid_mode=ON
enforce_gtid_consistency=1

4、接着是配置slave-02

[root@slave-02 ~]# vim /etc/my.cnf
[mysqld]
server_id=103
log_bin=mysql_bin
relay_log=relay_bin
log_slave_updates=on
gtid_mode=ON
enforce_gtid_consistency=1

完成以上配置文件的修改后,分别重启这三个节点上的MySQL服务:

[root@master ~]# systemctl restart mysqld
[root@slave-01 ~]# systemctl restart mysqld
[root@slave-02 ~]# systemctl restart mysqld

配置slave-01master的主从关系

mysql> stop slave;  -- 停止主从同步
mysql> change master to master_host='192.168.190.151', master_port=3306, master_user='repl', master_password='Abc_123456', master_auto_position=1;  -- 配置master节点的连接信息
mysql> start slave;  -- 启动主从同
-----------------------------------
©著作权归作者所有:来自51CTO博客作者ZeroOne01的原创作品,请联系作者获取转载授权,否则将追究法律责任
基于MHA搭建MySQL Replication集群高可用架构
https://blog.51cto.com/zero01/2468767

进入slave-01节点的MySQL命令行终端,分别执行如下语句来配置主从复制链路:

配置完主从复制链路后,使用show slave status\G;语句查看主从同步状态,Slave_IO_RunningSlave_SQL_Running的值均为Yes 才能表示主从同步状态是正常的:
alt


配置slave-02master的主从关系

mysql> stop slave;  -- 停止主从同步
mysql> change master to master_host='192.168.190.151', master_port=3306, master_user='repl', master_password='Abc_123456', master_auto_position=1;  -- 配置master节点的连接信息
mysql> start slave;  -- 启动主从同步

同样的步骤,进入slave-02节点的MySQL命令行终端,分别执行如下语句来配置主从复制链路:

配置完主从复制链路后,使用show slave status\G;语句查看主从同步状态,Slave_IO_RunningSlave_SQL_Running的值均为Yes 才能表示主从同步状态是正常的:
alt


配置ssh免密登录

配置集群内所有主机之间能够通过ssh免密登录,因为MHA是基于ssh去实现远程控制及数据管理的。例如,故障转移过程中保存原Master节点的二进制日志以及配置虚拟IP等。

1、生成ssh登录密钥:

[root@master ~]# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:LzRXziRQPrqaKEteH6KrZpCiV6uGP6GTi6RonE7Hhms root@master
The key's randomart image is:
+---[RSA 2048]----+
|        ...      |
|         o       |
|          + o    |
|         . B     |
| .      S . o    |
|+ + .  . =       |
|=Bo*o.. o .      |
|%EOo.+ + .       |
|%XB*. +          |
+----[SHA256]-----+

2、将密钥拷贝到其他服务器上:

[root@master ~]# ssh-copy-id -i /root/.ssh/id_rsa [email protected]
[root@master ~]# ssh-copy-id -i /root/.ssh/id_rsa [email protected]
[root@master ~]# ssh-copy-id -i /root/.ssh/id_rsa [email protected]
[root@master ~]# ssh-copy-id -i /root/.ssh/id_rsa [email protected]

然后到集群中其他节点上进行同样的操作,由于是重复的操作这里就不演示了。最后简单测试下能否正常免密登录即可:

[root@master ~]# ssh [email protected]
Last failed login: Sat Feb  1 15:29:38 CST 2020 from 192.168.190.151 on ssh:notty
There was 1 failed login attempt since the last successful login.  # 没有要求输入密码,测试成功
Last login: Sat Feb  1 14:14:03 2020 from 192.168.190.1
[root@slave-01 ~]# 

安装MHA软件包

1、首先在所有的节点上安装mha4mysql-node软件包,安装包可到如下地址进行下载:

下载好的rpm文件如下:

[root@master ~]# ls *.rpm
mha4mysql-node-0.58-0.el7.centos.noarch.rpm
[root@master ~]# 

在安装该rpm包之前需要先安装perl相关依赖:

[root@master ~]# yum -y install epel-release
[root@master ~]# yum -y install perl-DBD-MySQL perl-DBI ncftp

现在就可以安装mha4mysql-node了,命令如下:

  • **Tips:**另外的两个Slave节点和监控节点按如上步骤安装即可,这里就不重复演示了

2、接着是在监控节点manager上安装mha4mysql-manager软件包,安装包到如下地址进行下载:

[root@master ~]# rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm

下载好的rpm文件如下:

[root@manager ~]# ls *.rpm
mha4mysql-manager-0.58-0.el7.centos.noarch.rpm
[root@manager ~]# 

同样,在安装该rpm包之前需要先安装perl相关依赖:

[root@manager ~]# yum -y install epel-release
[root@manager ~]# yum -y install perl-Config-Tiny perl-Time-HiRes perl-Parallel-ForkManager perl-Log-Dispatch perl-DBD-MySQL ncftp

然后安装mha4mysql-manager包,命令如下:

[root@manager ~]# rpm -ivh mha4mysql-manager-0.58-0.el7.centos.noarch.rpm


配置MHA管理节点

1、创建MHA的配置文件存放目录和工作目录:

[root@manager ~]# mkdir /etc/mha
[root@manager ~]# mkdir /home/mysql_mha

2、创建MHA的配置文件,并添加如下内容:

[root@manager ~]# vim /etc/mha/mysql_mha.cnf
[server default]
# mha用于访问数据库的账户和密码
user=mha
password=Abc_123456
# 指定mha的工作目录
manager_workdir=/home/mysql_mha
# mha日志文件的存放路径
manager_log=/home/mysql_mha/manager.log
# 指定mha在远程节点上的工作目录
remote_workdir=/home/mysql_mha
# 可以使用ssh登录的用户
ssh_user=root
# 用于主从复制的MySQL用户和密码
repl_user=repl
repl_password=Abc_123456
# 指定间隔多少秒检测一次
ping_interval=1
# 指定master节点存放binlog日志文件的目录
master_binlog_dir=/var/lib/mysql
# 指定一个脚本,该脚本实现了在主从切换之后,将虚拟IP漂移到新的Master上
master_ip_failover_script=/usr/bin/master_ip_failover
# 指定用于二次检查节点状态的脚本
secondary_check_script=/usr/bin/masterha_secondary_check -s 192.168.190.151 -s 192.168.190.152 -s 192.168.190.154

#
 配置集群中的节点信息
[server1]
hostname=192.168.190.151
# 指定该节点可以参与Master选举
candidate_master=1

[server2]
hostname=192.168.190.152
candidate_master=1

[server3]
hostname=192.168.190.154
# 指定该节点不能参与Master选举
no_master=1

3、编写配置文件中所配置的master_ip_failover脚本,该脚本是根据MHA的官方示例修改的,MHA默认并没有提供。需要注意脚本中的几处地方需要根据实际情况进行修改,已用注释标明:

[root@manager ~]# vim /usr/bin/master_ip_failover
#!/usr/bin/env perl

use strict;
use warnings FATAL => 'all';

use Getopt::Long;

my (
    $command, $orig_master_host, $orig_master_ip,$ssh_user,
    $orig_master_port, $new_master_host, $new_master_ip,$new_master_port,
    $orig_master_ssh_port,$new_master_ssh_port,$new_master_user,$new_master_password
);

#
 这里定义的虚拟IP可以根据实际情况进行修改
my $vip = '192.168.190.80/24';
my $key = '1';
# 这里的网卡名称 “ens32” 需要根据你机器的网卡名称进行修改
my $ssh_start_vip = "sudo /sbin/ifconfig ens32:$key $vip";
my $ssh_stop_vip = "sudo /sbin/ifconfig ens32:$key down";
my $ssh_Bcast_arp= "sudo /sbin/arping -I bond0 -c 3 -A $vip";

GetOptions(
    'command=s'          => \$command,
    'ssh_user=s'         => \$ssh_user,
    'orig_master_host=s' => \$orig_master_host,
    'orig_master_ip=s'   => \$orig_master_ip,
    'orig_master_port=i' => \$orig_master_port,
    'orig_master_ssh_port=i' => \$orig_master_ssh_port,
    'new_master_host=s'  => \$new_master_host,
    'new_master_ip=s'    => \$new_master_ip,
    'new_master_port=i'  => \$new_master_port,
    'new_master_ssh_port' => \$new_master_ssh_port,
    'new_master_user' => \$new_master_user,
    'new_master_password' => \$new_master_password

);

exit &main();

sub main {
    $ssh_user = defined $ssh_user ? $ssh_user : 'root';
    print "\n\nIN SCRIPT TEST====$ssh_user|$ssh_stop_vip==$ssh_user|$ssh_start_vip===\n\n";

    if ( $command eq "stop" || $command eq "stopssh" ) {

        my $exit_code = 1;
        eval {
            print "Disabling the VIP on old master: $orig_master_host \n";
            &stop_vip();
            $exit_code = 0;
        };
        if ($@) {
            warn "Got Error: $@\n";
            exit $exit_code;
        }
        exit $exit_code;
    }
    elsif ( $command eq "start" ) {

        my $exit_code = 10;
        eval {
            print "Enabling the VIP - $vip on the new master - $new_master_host \n";
            &start_vip();
     &start_arp();
            $exit_code = 0;
        };
        if ($@) {
            warn $@;
            exit $exit_code;
        }
        exit $exit_code;
    }
    elsif ( $command eq "status" ) {
        print "Checking the Status of the script.. OK \n";
        exit 0;
    }
    else {
        &usage();
        exit 1;
    }
}

sub start_vip() {
    `ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
sub stop_vip() {
    `ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`;
}

sub start_arp() {
    `ssh $ssh_user\@$new_master_host \" $ssh_Bcast_arp \"`;
}
sub usage {
    print
    "Usage: master_ip_failover --command=start|stop|stopssh|status --ssh_user=user --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n";
}

还需要给该脚本添加可执行权限,否则MHA是无法调用的:

[root@manager ~]# chmod a+x /usr/bin/master_ip_failover

4、根据配置文件中remote_workdir的配置,需在其他节点上创建MHA的远程工作目录:

[root@master ~]# mkdir /home/mysql_mha
[root@slave-01 ~]# mkdir /home/mysql_mha
[root@slave-02 ~]# mkdir /home/mysql_mha

5、在配置文件中指定了让manager使用mha这个用户来访问数据库节点,所以需要在master节点上创建mha用户:

create user 'mha'@'%' identified with mysql_native_password by 'Abc_123456';
grant all privileges on *.* to 'mha'@'%';
flush privileges;

6、完成以上所有步骤后,在manager节点上使用masterha_check_sshmasterha_check_repl 对配置进行检查,其中masterha_check_ssh用于检查ssh登录是否正常,而masterha_check_repl则用于检查主从节点的复制链路是否正常:

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

执行结果如下:
alt

alt

7、以上检测都通过后,就可以启动MHA服务了。启动命令如下:

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

启动完成后,可以使用ps命令查看masterha_manager进程是否存在,如下存在则代表启动成功:

[root@manager ~]# ps aux |grep masterha_manager
root       2842  0.3  1.1 299648 22032 pts/0    S    18:30   0:00 perl /usr/bin/masterha_manager --conf=/etc/mha/mysql_mha.cnf
root       2901  0.0  0.0 112728   976 pts/0    R+   18:31   0:00 grep --color=auto masterha_manager
[root@manager ~]# 

8、最后我们需要到master节点上,手动去配置虚拟IP。因为MHA只会在主从切换时漂移虚拟IP到新的Master节点,而不会在第一次启动时主动去设置Master的虚拟IP,所以我们需要手动设置。设置虚拟IP的命令如下:

[root@master ~]# ifconfig ens32:1 192.168.190.80/24

设置成功后,使用ip addr命令可以看到网卡上绑定的虚拟IP:
alt


测试MHA服务

到此为止,我们就已经完成了MHA高可用架构的搭建,接下来我们对其进行一些简单的测试。例如,测试下是否能正常ping 通虚拟IP,毕竟应用端访问数据库时连接的是虚拟IP,所以首先得确保虚拟IP是能够被访问的。如下:
alt

ping通之后,使用Navicat等远程连接工具测试下能否正常通过虚拟IP连接上数据库:
alt

确定了虚拟IP能正常访问后,接着测试MHA是否能够正常进行主从切换,首先将master节点上的MySQL服务给停掉,模拟Master宕机:

[root@master ~]# systemctl stop mysqld

正常情况下,此时master节点上的网卡就不会再绑定该虚拟IP:
alt

而是会被MHA漂移到slave-01节点的网卡上,因为此时该Slave就是新的Master:
alt

接着进入slave-02节点上的MySQL命令行终端,确认下该Slave是否已经正常与新的Master进行同步。之前我们配置slave-02 的主库是master,现在将master停掉后,可以看到slave-02Master_Host已经被MHA切换成了slave-01的IP:
alt

经过以上测试后,可以看到我们搭建的MHA架构是能够正常运行的,已经使得Replication集群拥有了基本的高可用能力,即便Master下线后也能正常从Slave中选举新的Master并进行切换,也正确建立了其他Slave与新Master的复制链路。


MHA架构优缺点

优点:

  • 使用Perl脚本语言开发并且完全开源,开发者可以根据自己的需求进行二次开发
  • 能够支持基于GTID和基于日志点的复制模式
  • MHA在进行故障转移时更不易产生数据丢失
  • 在一个监控节点上可以监控多个Replication集群

缺点:

  • MHA默认不提供虚拟IP功能,需要自行编写脚本或利用第三方工具来实现虚拟IP的配置
  • MHA启动后只会对Master进行监控,不会对Slave进行监控,也无法监控复制链路的情况
  • 集群环境需要能够通过 ssh免密登录,存在一定的安全隐患
  • MHA没有提供对Slave的读负载均衡功能,需要通过第三方工具来实现

本文由 mdnice 多平台发布

Guess you like

Origin blog.csdn.net/njpkhuan/article/details/132798707