MySQL高可用MHA实战

时间:2022-08-10 01:20:06

MySQL高可用架构MHA介绍

简介:
MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,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/

MHA的工作原理图如下:
MySQL高可用MHA实战

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

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

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

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

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

(6)使其他的slave连接新的master进行复制;

MHA软件由两部分组成,Manager工具包和Node工具包,具体的说明如下。

Manager工具包主要包括以下几个工具:

masterha_check_ssh      检查MHA的SSH配置状况
masterha_check_repl 检查MySQL复制状况
masterha_manger 启动MHA
masterha_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线程)

注意:
为了尽可能的减少主库硬件损坏宕机造成的数据丢失,因此在配置MHA的同时建议配置成MySQL 5.5的半同步复制。

1.CentOS7 下MySQL的MHA配置安装

1.1 MySQL安装以及主从配置

1.1.1环境
 192.168.2.132 mydb1   #Master                CENTOS7
192.168.2.133 mydb2 #Slave CENTOS7
192.168.2.131 mydb3 #MHAManager CENTOS7
1.1.2mydb1 mybd2 安装MySQL5.6
1.1.3配置复制
#主从上
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'root123' WITH GRANT OPTION;
GRANT ALL PRIVILEGES ON *.* TO 'root'@'127.0.0.1' IDENTIFIED BY 'root123' WITH GRANT OPTION;
GRANT ALL PRIVILEGES ON *.* TO 'root'@'192.%' IDENTIFIED BY 'root123' WITH GRANT OPTION;
GRANT replication slave on *.* to 'rep'@'192.168.2.132' identified by 'rep123';
GRANT replication slave on *.* to 'rep'@'192.168.2.133' identified by 'rep123';

#主机上
show master status \G;

#从机上
change master to
master_host='192.168.2.132',
master_port=3306,
master_user='rep',
master_password='rep123',
master_log_file='binlog.000005',
master_log_pos=120;

1.2MHA部署

1.2.1 各服务器修改hostname,配置hosts文件
 #每台服务器上执行
vi /etc/hosts
192.168.2.132 mydb1 #Master
192.168.2.133 mydb2 #Slave
192.168.2.131 mydb3 #MHAManager
1.2.2 各服务器间配置ssh免密码

#root用户操作(/root),pwd

mkdir ~/.ssh
chmod 700 ~/.ssh
cd ~/.ssh
ssh-keygen -t rsa #一直回车
ls -al
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ls -al
chmod 600 ~/.ssh/authorized_keys
cd ..
scp -r .ssh 192.168.2.132:/root/
scp -r .ssh 192.168.2.133:/root/

ssh mydb1
ssh mydb2
ssh mydb3
1.2.3 每个节点部署node

CentOS 添加yum源
因为有很多依赖包,如果没下载完整会报各种各样的错误。默认的yum源很多pkg都没法下载。

#1. Download the latest epel-release rpm from
http://dl.fedoraproject.org/pub/epel/7/x86_64/e/
#2. Install epel-release rpm:
rpm -Uvh epel-release*rpm
# 3.Install perl-Log-Dispatch rpm package:
yum install perl-Log-Dispatch

安装依赖包

yum install perl-DBD-MySQL
yum install perl-DBI
yum install mysql-libs
yum install perl-CPAN
yum install perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker

tar xzvf mha4mysql-node-0.56.tar.gz
cd mha4mysql-node-0.56
perl Makefile.PL
make && make install
1.2.4 管理节点部署MHA-manger
yum   install -y perl perl-Config-Tiny perl-Email-Date-Forma \
perl-Log-Dispatch perl-MIME-Liteperl-MIME-Types perl-Mail-Sender \
perl-Mail-Sendmail perl-MailTools \
perl-Parallel-ForkManagerperl-Params-Validate perl-Time-HiRes \
perl-TimeDate


tar xzvf mha4mysql-manager-0.56.tar.gz
cd mha4mysql-manager-0.56
perl Makefile.PL
make && make install
1.2.5 编辑配置文件

创建相关目录

[root@mydb3 mha4mysql-manager-0.56]#   mkdir -p /u01/mha/log
[root@mydb3 mha4mysql-manager-0.56]# mkdir -p /u01/mha/etc/app
[root@mydb3 mha4mysql-manager-0.56]# cp samples/conf/* /u01/mha/etc/

修改app.cnf配置文件

[root@mydb3 mha4mysql-manager-0.56]#   vi /u01/mha/etc/app.cnf 
[server default]
user = root #设置监控用户root
password = root123 #设置mysql中root用户的密码,这个密码是前文中创建监控用户的那个密码
ssh_user = root #设置ssh的登录用户名
repl_user = rep #设置复制环境中的复制用户名
repl_password = rep123 #设置复制用户的密码
ping_interval = 1 #设置监控主库,发送ping包的时间间隔,默认是3秒,尝试三次没有回应的时候自动进行railover
ping_type = SELECT

manager_workdir=/u01/mha/etc/app #设置manager的工作目录
manager_log=/u01/mha/log/manager.log #设置manager的日志
remote_workdir=/u01/mha/etc/app #设置远端mysql在发生切换时binlog的保存位置
master_binlog_dir="/MySQL/my3306/log/binlog/" #设置master 保存binlog的位置,以便MHA可以找到master的日志,我这里的也就是mysql的数据目录

master_ip_failover_script="/u01/mha/etc/master_ip_failover" #设置自动failover时候的切换脚本
master_ip_online_change_script="/u01/mha/etc/master_ip_failover" #设置手动切换时候的切换脚本

shutdown_script="" #设置故障发生后关闭故障主机脚本(该脚本的主要作用是关闭主机放在发生脑裂,这里没有使用)

report_script="" #设置发生切换后发送的报警的脚本

#check_repl_delay=0 #默认情况下如果一个slave落后master 100M的relay logs的话,MHA将不会选择该slave作为一个新的master,因为对于这个slave的恢复需要花费很长时间,通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时,这个参数对于设置了candidate_master=1的主机非常有用,因为这个候选主在切换的过程中一定是新的master

[server1]
hostname=mydb1
port=3306
master_binlog_dir="/MySQL/my3306/log/binlog/"
candidate_master=1 #设置为候选master,如果设置该参数以后,发生主从切换以后将会将此从库提升为主库,即使这个主库不是集群中事件最新的slave
ignore_fail=1

[server2]
hostname=mydb2
port=3306
master_binlog_dir="/MySQL/my3306/log/binlog/"
candidate_master=1
ignore_fail=1

执行masterha_check_ssh检查ssh配置

[root@mydb3 etc]# /usr/local/bin/masterha_check_ssh --conf=/u01/mha/etc/app.cnf
Thu Aug 10 11:56:03 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Thu Aug 10 11:56:03 2017 - [info] Reading application default configuration from /u01/mha/etc/app.cnf..
Thu Aug 10 11:56:03 2017 - [info] Reading server configuration from /u01/mha/etc/app.cnf..
Thu Aug 10 11:56:03 2017 - [info] Starting SSH connection tests..
Thu Aug 10 11:56:03 2017 - [debug]
Thu Aug 10 11:56:03 2017 - [debug] Connecting via SSH from root@mydb1(192.168.2.132:22) to root@mydb2(192.168.2.133:22)..
Thu Aug 10 11:56:03 2017 - [debug] ok.
Thu Aug 10 11:56:04 2017 - [debug]
Thu Aug 10 11:56:03 2017 - [debug] Connecting via SSH from root@mydb2(192.168.2.133:22) to root@mydb1(192.168.2.132:22)..
Thu Aug 10 11:56:04 2017 - [debug] ok.
Thu Aug 10 11:56:04 2017 - [info] All SSH connection tests passed successfully.

** 可以看见各个节点ssh验证都是ok的。**

配置切换脚本 master_ip_failover(VIP采用手动配置的方式)
修改完成后内容如下,而且如果使用脚本管理vip的话,需要手动在master服务器上绑定一个vip

[root@mydb1 bin]# /sbin/ifconfig ens33:1 192.168.2.201/24

脚本如下

[root@mydb3 etc]# vi /u01/mha/etc/master_ip_failover
#!/usr/bin/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.2.201/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig ens33::$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";
}

检查整个复制环境状况

[root@mydb3 etc]# /usr/local/bin/masterha_check_repl --conf=/u01/mha/etc/app.cnf
Thu Aug 10 15:47:33 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Thu Aug 10 15:47:33 2017 - [info] Reading application default configuration from /u01/mha/etc/app.cnf..
Thu Aug 10 15:47:33 2017 - [info] Reading server configuration from /u01/mha/etc/app.cnf..
Thu Aug 10 15:47:33 2017 - [info] MHA::MasterMonitor version 0.56.
Thu Aug 10 15:47:35 2017 - [info] GTID failover mode = 0
Thu Aug 10 15:47:35 2017 - [info] Dead Servers:
Thu Aug 10 15:47:35 2017 - [info] Alive Servers:
Thu Aug 10 15:47:35 2017 - [info] mydb1(192.168.2.132:3306)
Thu Aug 10 15:47:35 2017 - [info] mydb2(192.168.2.133:3306)
Thu Aug 10 15:47:35 2017 - [info] Alive Slaves:
Thu Aug 10 15:47:35 2017 - [info] mydb2(192.168.2.133:3306) Version=5.6.36-log (oldest major version between slaves) log-bin:enabled
Thu Aug 10 15:47:35 2017 - [info] Replicating from 192.168.2.132(192.168.2.132:3306)
Thu Aug 10 15:47:35 2017 - [info] Primary candidate for the new Master (candidate_master is set)
Thu Aug 10 15:47:35 2017 - [info] Current Alive Master: mydb1(192.168.2.132:3306)
Thu Aug 10 15:47:35 2017 - [info] Checking slave configurations..
Thu Aug 10 15:47:35 2017 - [info] read_only=1 is not set on slave mydb2(192.168.2.133:3306).
Thu Aug 10 15:47:35 2017 - [warning] relay_log_purge=0 is not set on slave mydb2(192.168.2.133:3306).
Thu Aug 10 15:47:35 2017 - [info] Checking replication filtering settings..
Thu Aug 10 15:47:35 2017 - [info] binlog_do_db= , binlog_ignore_db=
Thu Aug 10 15:47:35 2017 - [info] Replication filtering check ok.
Thu Aug 10 15:47:35 2017 - [info] GTID (with auto-pos) is not supported
Thu Aug 10 15:47:35 2017 - [info] Starting SSH connection tests..
Thu Aug 10 15:47:36 2017 - [info] All SSH connection tests passed successfully.
Thu Aug 10 15:47:36 2017 - [info] Checking MHA Node version..
Thu Aug 10 15:47:36 2017 - [info] Version check ok.
Thu Aug 10 15:47:36 2017 - [info] Checking SSH publickey authentication settings on the current master..
Thu Aug 10 15:47:36 2017 - [info] HealthCheck: SSH to mydb1 is reachable.
Thu Aug 10 15:47:36 2017 - [info] Master MHA Node version is 0.56.
Thu Aug 10 15:47:36 2017 - [info] Checking recovery script configurations on mydb1(192.168.2.132:3306)..
Thu Aug 10 15:47:36 2017 - [info] Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/MySQL/my3306/log/binlog/ --output_file=/u01/mha/etc/app/save_binary_logs_test --manager_version=0.56 --start_file=binlog.000005
Thu Aug 10 15:47:36 2017 - [info] Connecting to root@192.168.2.132(mydb1:22)..
Creating /u01/mha/etc/app if not exists..ok.
Checking output directory is accessible or not..
ok.
Binlog found at /MySQL/my3306/log/binlog/, up to binlog.000005
Thu Aug 10 15:47:36 2017 - [info] Binlog setting check done.
Thu Aug 10 15:47:36 2017 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers..
Thu Aug 10 15:47:36 2017 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user='root' --slave_host=mydb2 --slave_ip=192.168.2.133 --slave_port=3306 --workdir=/u01/mha/etc/app --target_version=5.6.36-log --manager_version=0.56 --relay_log_info=/MySQL/my3306/log/relay-log.info --relay_dir=/MySQL/my3306/data/ --slave_pass=xxx
Thu Aug 10 15:47:36 2017 - [info] Connecting to root@192.168.2.133(mydb2:22)..
Checking slave recovery environment settings..
Opening /MySQL/my3306/log/relay-log.info ... ok.
Relay log found at /MySQL/my3306/log, up to relaylog.000005
Temporary relay log file is /MySQL/my3306/log/relaylog.000005
Testing mysql connection and privileges..Warning: Using a password on the command line interface can be insecure.
done.
Testing mysqlbinlog output.. done.
Cleaning up test file(s).. done.
Thu Aug 10 15:47:37 2017 - [info] Slaves settings check done.
Thu Aug 10 15:47:37 2017 - [info]
mydb1(192.168.2.132:3306) (current master)
+--mydb2(192.168.2.133:3306)

Thu Aug 10 15:47:37 2017 - [info] Checking replication health on mydb2..
Thu Aug 10 15:47:37 2017 - [info] ok.
Thu Aug 10 15:47:37 2017 - [info] Checking master_ip_failover_script status:
Thu Aug 10 15:47:37 2017 - [info] /u01/mha/etc/master_ip_failover --command=status --ssh_user=root --orig_master_host=mydb1 --orig_master_ip=192.168.2.132 --orig_master_port=3306


IN SCRIPT TEST====/sbin/ifconfig ens33::1 down==/sbin/ifconfig ens33:1 192.168.2.201/24===

Checking the Status of the script.. OK
Thu Aug 10 15:47:37 2017 - [info] OK.
Thu Aug 10 15:47:37 2017 - [warning] shutdown_script is not defined.
Thu Aug 10 15:47:37 2017 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.

为了防止脑裂发生,推荐生产环境采用脚本的方式来管理虚拟ip,而不是使用keepalived来完成。到此为止,基本MHA集群已经配置完毕。接下来就是实际的测试环节了。通过一些测试来看一下MHA到底是如何进行工作的。下面将从MHA自动failover,我们手动failover,在线切换三种方式来介绍MHA的工作情况。

开启MHA Manager监控

[root@mydb3 etc]#  /usr/local/bin/masterha_manager --conf=/u01/mha/etc/app.cnf &
[1] 20220
[root@mydb3 etc]# Thu Aug 10 16:38:13 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Thu Aug 10 16:38:13 2017 - [info] Reading application default configuration from /u01/mha/etc/app.cnf..
Thu Aug 10 16:38:13 2017 - [info] Reading server configuration from /u01/mha/etc/app.cnf..

启动参数介绍:

--remove_dead_master_conf 该参数代表当发生主从切换后,老的主库的ip将会从配置文件中移除。

--manger_log 日志存放位置

--ignore_last_failover 在缺省情况下,如果MHA检测到连续发生宕机,且两次宕机间隔不足8小时的话,则不会进行Failover,之所以这样限制是为了避免ping-pong效应。该参数代表忽略上次MHA触发切换产生的文件,默认情况下,MHA发生切换后会在日志目录,产生app1.failover.complete文件,下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换,除非在第一次切换后收到删除该文件,为了方便,这里设置为--ignore_last_failover。

查看启动日志
[root@mydb3 mha]# tail -n20 /u01/mha/log/manager.log
Testing mysqlbinlog output.. done.
Cleaning up test file(s).. done.
Thu Aug 10 16:38:16 2017 - [info] Slaves settings check done.
Thu Aug 10 16:38:16 2017 - [info]
mydb1(192.168.2.132:3306) (current master)
+--mydb2(192.168.2.133:3306)

Thu Aug 10 16:38:16 2017 - [info] Checking master_ip_failover_script status:
Thu Aug 10 16:38:16 2017 - [info] /u01/mha/etc/master_ip_failover --command=status --ssh_user=root --orig_master_host=mydb1 --orig_master_ip=192.168.2.132 --orig_master_port=3306


IN SCRIPT TEST====/sbin/ifconfig ens33::1 down==/sbin/ifconfig ens33:1 192.168.2.201/24===

Checking the Status of the script.. OK
Thu Aug 10 16:38:16 2017 - [info] OK.
Thu Aug 10 16:38:16 2017 - [warning] shutdown_script is not defined.
Thu Aug 10 16:38:16 2017 - [info] Set master ping interval 1 seconds.
Thu Aug 10 16:38:16 2017 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Thu Aug 10 16:38:16 2017 - [info] Starting ping health check on mydb1(192.168.2.132:3306)..
Thu Aug 10 16:38:16 2017 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..

其中"Ping(SELECT) succeeded, waiting until MySQL doesn't respond.."说明整个系统已经开始监控了。

关闭MHA Manager监控

[root@mydb3 mha]# /usr/local/bin/masterha_stop --conf=/u01/mha/etc/app.cnf
Stopped app successfully.

2.MHA failover故障切换写出详细操作步骤(切换成功截图))

环境
 192.168.2.132 mydb1   #Master               CENTOS7
192.168.2.133 mydb2 #Slave CENTOS7
192.168.2.131 mydb3 #MHAManager CENTOS7

MySQL高可用MHA实战
切换前的集群检测,可以看到,集群OK 主库 mydb1 从库 mydb2

2.1 模拟主库宕机

[root@mydb3~]# ssh mydb1 "pkill -9 mysqld"
MySQL高可用MHA实战

2.2 查看管理节点日志,可以看到VIP已经漂移

[root@mydb3 ~]# cat /u01/mha/log/manager.log |grep -i vip
MySQL高可用MHA实战
可以看到VIP已经从mydb1漂移到mydb2上了

2.3 验证VIP是否位于节点mydb2

[root@mydb3 ~]# ssh mydb2 "ifconfig |grep 2.201 -B1"
MySQL高可用MHA实战

2.4 查看管理节点MHA切换日志

 [root@mydb3 ~]# tail /u01/mha/log/manager.log

MySQL高可用MHA实战

2.5 查看new master(old slave)

show master status\G

MySQL高可用MHA实战

2.6 new slave(old:master)

 (1)打开MySQL
mysqld_safe --defaults-file=/u01/my3306/my.cnf &

MySQL高可用MHA实战

 (2)检查数据库
show master status\G
show slave status\G

MySQL高可用MHA实战

    cat /u01/mha/log/manager.log |grep -i change

MySQL高可用MHA实战

 (4)在slave连接master
CHANGE MASTER TO
MASTER_HOST='192.168.2.133',
MASTER_PORT=3306,
MASTER_LOG_FILE='binlog.000005',
MASTER_LOG_POS=120,
MASTER_USER='rep',
MASTER_PASSWORD='rep123';


start slave;

MySQL高可用MHA实战

2.7 启动管理节点

/usr/local/bin/masterha_manager --conf=/u01/mha/etc/app.cnf &
或者
/usr/local/bin/masterha_manager --conf=/u01/mha/etc/app.cnf --ignore_last_failover &

MySQL高可用MHA实战

可以看到主从已经做了切换。

3.MHA switchover线上切换

环境
 192.168.2.132 mydb1   #Slave                CENTOS7
192.168.2.133 mydb2 #Master CENTOS7
192.168.2.131 mydb3 #MHAManager CENTOS7

3.1 master:关闭event_scheduler(即192.168.2.133)

mysql> set global event_scheduler=off;

MySQL高可用MHA实战

3.2 manager:关闭管理进程 (即192.168.2.131)

[root@mydb3 mha]# /usr/local/bin/masterha_stop --conf=/u01/mha/etc/app.cnf

MySQL高可用MHA实战

3.3 manager:检查配置文件

/u01/mha/etc/app.cnf  有没有被修改破坏。如果破坏需要重新编辑正确配置文件:/u01/mha/etc/app.cnf
cp /u01/mha/etc/app.cnf.bak /u01/mha/etc/app.cnf

3.4 开始切换:

/usr/local/bin/masterha_master_switch --master_state=alive --conf=/u01/mha/etc/app.cnf

MySQL高可用MHA实战
MySQL高可用MHA实战

3.5 new master(old slave) mydb1

mysql> show master status\G

MySQL高可用MHA实战)

3.6 new slave(old master) mydb2

    CHANGE MASTER TO
MASTER_HOST='192.168.2.132',
MASTER_PORT=3306,
MASTER_LOG_FILE='binlog.000006',
MASTER_LOG_POS=120,
MASTER_USER='rep',
MASTER_PASSWORD='rep123';

mysql> start slave;
mysql> show slave status\G

MySQL高可用MHA实战

3.7 启动管理节点 查看集群状态

[root@mydb3 mha]# /usr/local/bin/masterha_manager --conf=/u01/mha/etc/app.cnf &
#或者
[root@mydb3 mha]# /usr/local/bin/masterha_manager --conf=/u01/mha/etc/app.cnf --remove_dead_master_conf --ignore_last_failover
[root@mydb3 mha]# /usr/local/bin/masterha_check_repl --conf=/u01/mha/etc/app.cnf

MySQL高可用MHA实战
MySQL高可用MHA实战
可以看到 切换成功 mydb1成为新的主库

4.踩过的一些坑

4.1 依赖包的问题

我的系统是centos 默认的yum 源很多包都找不到
MySQL高可用MHA实战
找到一个新的yum源
http://dl.fedoraproject.org/pub/epel/7/x86_64/e/
添加到yum源 就可以下载需要的包了

4.2 /usr/bin/perl^M: 坏的解释器: 没有那个文件或目录

master_ip_failover这个脚本是拿perl写的,放到机器上,运行集群检测时报错,提示很简单:没有那个文件或目录!
原因:
是因为脚本文件在windows下编辑过,windows下,每一行的结尾是\n\r,在Linux下文件的结尾是\n,那么你在windows下编辑过的文件在linux下打开看的时候每一行的结尾就会多出来一个字符\r, 用cat -A urfile时你可以看到这个\r字符被显示为^M。
解决方案
这时候只需要删除这个字符就可以了。可以使用命令:

sed -i 's/\r$//' yourfile

4.3 Can't exec "mysqlbinlog"/ Can't exec "mysql"

Can't exec "mysqlbinlog": No such file or directory at /usr/local/share/perl5/MHA/BinlogManager.pm line 99.
mysqlbinlog version not found!
Testing mysql connection and privileges..sh: mysql: command not found
解决方法如下,添加软连接(所有节点)

ln -s /usr/local/mysql/bin/mysqlbinlog /usr/local/bin/mysqlbinlog
ln -s /usr/local/mysql/bin/mysql /usr/local/bin/mysql