本文深入探讨MHA（Master High Availability）在MySQL高可用环境中的应用，详细讲解其架构、部署步骤及故障切换机制。MHA能实现快速故障转移，确保数据一致性，适用于一主多从场景。
MHA简介
MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。生产环境下的mysql主从复制群集，一旦主数据库发生宕机等意外情况使得数据库无法正常运转时，MHA可以将从数据库群集的其中一台MHA能做到在0~30秒之内自动完成数据库的故障切换操作，成为主库，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。该软件由两部分组成：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，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。我们自己使用其实也可以使用1主1从，但是master主机宕机后无法切换，以及无法补全binlog。master的mysqld进程crash后，还是可以切换成功，以及补全binlog的。
官方介绍：https://code.google.com/p/mysql-master-ha/
图01展示了如何通过MHA Manager管理多组主从复制。可以将MHA工作原理总结为如下：
MHA软件由两部分组成，Manager工具包和Node工具包，具体的说明如下。
masterha_check_ssh 检查MHA的SSH配置状况
masterha_check_repl 检查MySQL复制状况
masterha_manger 启动
MHAmasterha_check_status 检测当前MHA运行状态
masterha_master_monitor 检测master是否宕机
masterha_master_switch 控制故障转移（自动或者手动）
masterha_conf_host 添加或删除配置的server信息
Node工具包（这些工具通常由MHA Manager的脚本触发，无需人为操作）主要包括以下几个工具：
save_binary_logs 保存和复制master的二进制日志
apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的slave
filter_mysqlbinlog 去除不必要的ROLLBACK事件（MHA已不再使用这个工具）
purge_relay_logs 清除中继日志（不会阻塞SQL线程）
1.1部署MHA
部署MHA，具体的搭建环境如下（所有操作系统均为centos 7.5 64bit）
一共需要四台机器：Manager:192.168.88.5
Master:192.168.88.222
Slave:192.168.88.223
Slave:192.168.88.221
首先，关闭四台机器的防火墙。
四台机器设置ssh两两无密码登录；ssh-keygen -t rsa -P ‘’
2）把公钥分配到被控端主机
[root@master]# ssh-copy-id root@192.168.88.222
[root@master]# ssh-copy-id root@192.168.32.223
[root@master]# ssh-copy-id root@192.168.32.221
注意：四台机器都要进行此操作！
在部署MHA环境之前，首先要将数据库的主从复制环境部署好（这里主从复制环境省略，但是需要提一点在搭建主从复制环境配置两台slave数据库的文件时（/etc/my.cnf）,需要添加“log_bin=on”这个选项）。
2.1 安装mha-node
1.在master和slave端（三台机器）上传mysql-node并解压数据包：
[root@192 ~]# tar xf mha4mysql-node-0.56.tar.gz
2.下载相关依赖包：
yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch
perl-Parallel-ForkManager perl-Time-HiRes
perl-ExtUtils-MakeMaker -y –skip-broken
yum install perl-CPAN -y
-
用eprl检查是否缺少依赖包，如果正常，下面则会显示looks good。
[root@192 mha4mysql-node-0.56]# perl Makefile.PL -
进行安装编译
Make && make install
5.安装成功后会在这个目录下生成一写脚本
[root@192.168.0.50 bin]# pwd
/usr/local/bin
[root@192.168.0.50 bin]# ll
total 40
-r-xr-xr-x 1 root root 15498 Apr 20 10:05 apply_diff_relay_logs
-r-xr-xr-x 1 root root 4807 Apr 20 10:05 filter_mysqlbinlog
-r-xr-xr-x 1 root root 7401 Apr 20 10:05 purge_relay_logs
-r-xr-xr-x 1 root root 7263 Apr 20 10:05 save_binary_logs
至此mha-node端已安装完毕。
2.2安装mha-manager
- 在manager(192.168.88.222)端上传mha-manager。
注意：在安装manager软件时，需要首先安装node，两个软件需要一起安装。
2.解包并进入目录：
tar xf mha4mysql-manager-0.56.tar(1).gz
cd mha4mysql-manager-0.56/
3.安装相关依赖包：
yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes perl-ExtUtils-MakeMaker –y –skip-broken
yum install perl-CPAN –y
下载gcc-c++
4.检查依赖包安装情况：
perl Makefile.PL
[root@192 mha4mysql-manager-0.56]# perl Makefile.PL
*** Module::AutoInstall version 1.03
*** Checking for Perl dependencies…
[Core Features]
- DBI …loaded. (1.627)
- DBD::mysql …loaded. (4.023)
- Time::HiRes …loaded. (1.9725)
- Config::Tiny …loaded. (2.14)
- Log::Dispatch …missing.
- Parallel::ForkManager …missing.
- MHA::NodeConst …loaded. (0.56)
==> Auto-install the 2 mandatory module(s) from CPAN? [y]
发现缺少Log::Dispatch，Parallel::ForkManager两个依赖包，这里使用yum无法安装，需要进入perl -MCPAN -e shell。
5.进入安装界面，进行安装：
install Log::Dispatch, install Parallel::ForkManager
安装完毕后退出安装界面重新输入perl Makefile.PL，此时所有依赖包已安装完毕。
6.编译：
make && make install
7.Mha-manager 安装完毕。
2.2 编写MHA配置文件，以及进行相关调整
- 在manager端创建配置文件目录并编写配置文件：
mkdir –p /etc/mha/
vim /etc/mha/app1.cnf
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/usr/local/mysql/data/
password=pwd123
ping_interval=1
remote_workdir=/tmp
repl_password=pwd123
repl_user=myslave
ssh_user=root
user=root
[server1]
hostname=192.168.88.223
port=3306
[server2]
candidate_master=1
hostname=192.168.88.221
port=3306
[server3]
hostname=192.168.88.222
port=3306
2.创建相关目录文件
mkdir -p /var/log/mha/app1/ 创建mha目录
touch /var/log/mha/app1/manager 创建mha文件
3.在master数据库创建监控用户：
grant all privileges on . to ‘root’@‘192.168.88.%’ identified by ‘pwd123’;
flush privileges;
4.在master数据库进行授权：
GRANT ALL ON . TO ‘myslave’@‘192.168.88.%’ IDENTIFIED BY ‘pwd123’;
5.两台slave数据库设置对外提供读服务：
mysql -e ‘set global read_only=1’ -ppwd123(两台slave数据库执行)
mysql -e ‘set global relay_log_purge=0’ –ppwd123(两台slave数据库执行)
- 在manager端用命令检查ssh的连通性。
[root@localhost ~]# masterha_check_ssh --conf=/etc/mha/app1.cnf
7.在所有slave节点添加以下两条软连接。
ln -s /usr/local/mysql/bin/mysqlbinlog /usr/local/bin/mysqlbinlog
ln -s /usr/local/mysql/bin/mysql /usr/local/bin/mysql
- 检查配置文件中的脚本以及整个群集有无问题。
[root@localhost ~]# masterha_check_repl --conf=/etc/mha/app1.cnf
9.全部检查后在manager端检查mha监控状态，此时由于没有开启mha 监控，所以状态为stop。
masterha_check_status --conf=/etc/masterha/app1.cnf
app1 is stopped(2:NOT_RUNNING).
10.因为开启mha命令需要用到manager.log日志文件，所以需要事先新建目录文件：
Mkdir –p /var/log/mha/app1/manager.log
11.MHA命令开启监控
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
- 查看监控主机以及监控状态。
[root@localhost ~]# masterha_check_status --conf=/etc/mha/app1.cnf
到目前为止，所有环境以及监控都已部署完成。
2.2 测试MHA基本数据库故障转移功能
-
由于整个环境已经被mha监控，此时我们可以模拟主数据库故障，查看mha软件是否已经生效。
-
在master数据库端停掉数据库：
3.查看slave1，发现此时slave1已经成为master端，并且原来的slave状态全部清空
4.查看slave2，发现主从复制环境的master端已经由原来的master转为slave1,
说明部署的MHA基本功能已经完成，测试成功！
2.3 修复主从复制环境，并重新开启mha监控环境
1.在原master端宕掉后，我们可以看到这样的现象：
（1） 主数据库进行了转移；
（2） slave2对应的主数据库从原来的master转移到了slave1上；
（3） mha-manager的配置文件/etc/mha/app1.cnf的原master由于不在监控中了，所以mha在配置文件中将其删除。
（4） 现在用命令查看mha状态，由于环境已经不符合mha的监控环境，所以mha已经停止（stop）；
-
在管理员发现宕机后要及时进行主从复制环境以及，mha环境的修复。
-
在master端查看偏移量
5.在slave端重启slave并进入数据库，进行主从复制环境的搭建：
[root@localhost ~]# systemctl restart mysqld
Start slave;
Show slave status\G
-
在manager配置文件添加上新加入的slave字段；
-
重新启动mha软件：
[root@localhost ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
7.查看监控状态：
[root@localhost ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:32131) is running(0:PING_OK), master:192.168.88.223
2.4 使用master_ip_failover达到虚拟IP随主数据库切换而漂移的效果。
1．在master端添加一个漂移地址：
- 在manager端修改配置文件/etc/mha/app1.cnf
把切换脚本添加到配置文件：
master_ip_failover_script=/usr/local/bin/master_ip_failover
因为测试软件自带的脚本没有成功，所以自己对脚本进行了修改，修改后只需将漂移地址（红色）进行修改即可，脚本如下：
#!/usr/bin/env perl
use strict;
use warnings FATAL => ‘all’;
use Getopt::Long;
my (
$command, $ssh_user, $orig_master_host, $orig_master_ip,
$orig_master_port, $new_master_host, $new_master_ip, $new_master_port
);
my $vip = ‘192.168.0.88/24’;
my $key = ‘1’;
my sshstartvip="/sbin/ifconfigeth1:ssh_start_vip = "/sbin/ifconfig eth1:sshstartvip="/sbin/ifconfigeth1:key $vip";
my sshstopvip="/sbin/ifconfigeth1:ssh_stop_vip = "/sbin/ifconfig eth1:sshstopvip="/sbin/ifconfigeth1:key down";
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,
‘new_master_host=s’ => $new_master_host,
‘new_master_ip=s’ => $new_master_ip,
‘new_master_port=i’ => $new_master_port,
);
exit &main();
sub main {
print "\n\nIN SCRIPT TEST====$ssh_stop_vip==$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();
$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() {
return 0 unless ($ssh_user);
ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \";
}
sub usage {
print
“Usage: master_ip_failover --command=start|stop|stopssh|status --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”;
}
- 测试脚本：
（1） 查看mha监控是否开启；
masterha_check_status–conf=/etc/mha/app1.cnf
（2） 关闭master数据库；
（3） 查看主数据库是否转移；
（4） 查看漂移地址是否转移到现在的主数据库；
（5） 漂移地址故障转移成功；
2.5 MHA Binlog_Server
为了防止ssh 无法连接，避免主库连接不上而导致的从库与主库二进制日志有差异而丢失部分数据，所以需要开启一台mysql.server开启binlog数据补偿功能。这里我们用第二台slave开启此功能。
- 在manager端/etc/mha/app1.cnf配置文件中添加binlog字段：
[binlog1]
no_master=1
hostname=192.168.88.221
master_binlog_dir=/data/binserver
2.在slave2中创建相关目录并授予权限：
mkdir -p /data/binserver
chown -R mysql.mysql /data/*
3.进入目录：
cd /data/binserver/
4.用命令拉取主端数据库的二进制日志（注意此时拉取的二进制日志是最新的日志）
mysqlbinlog -R --host=192.168.88.222 --usr=myslave --password=pwd123 --raw --stop-never master-bin.000004 &
5.查看拉取的日志：
- 在主数据库master端更新二进制日志；
mysql> flush logs;
Query OK, 0 rows affected (0.01 sec)
在从端用ll命令可以看到新更新的日志。
- 因为刚刚修改外配置文件，需要重启mha:
[root@localhost ~]# masterha_stop --conf=/etc/mha/app1.cnf
[root@localhost ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
[1] 82440
2.6 管理员的职责
1.部署MHA+VIP+BinlogServer
2.监控机故障处理修复环境
3.高可用架构的优化
核心是：尽可能降低主从复制的延时，让MHA花在数据补偿上的时间尽量减少。尽量让从数据库保持正常，不宕机。
问题：GTID，send-report
扫一扫
254
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
