Step By Step 搭建 MySql MHA 集群-阿里云开发者社区

关于MHA

MHA（Master High Availability）是一款开源的mysql高可用程序，目前在mysql高可用方面是一个相对成熟的解决方案。MHA 搭建的前提是MySQL集群中已经搭建了MySql Replication环境，有了Master/Slave节点。MHA的主要作用就是监测到Master节点故障时会提升主从复制环境中拥有最新数据的Slave节点成为新的master节点。同时，在切换master期间，MHA会通过从其他的Slave节点来获取额外的信息来避免一致性的问题，整个的切换过程对于应用程序而言是完全透明的。MHA还提供了master节点在线切换功能，即按需切换master/slave节点。

MHA Manager 和 MHA Node

MHA 服务有两个角色，MHA Manager 和 MHA Node
MHA Manager: 通常单独部署在一台独立机器上管理 master/slave 集群，每个master/slave 集群可以理解为一个application。

MHA Node: 运行在每台mysql 服务器(master/slave)上。它通过监控具备解析和清理logs功能来加快故障转移。

整体上的架构如下图所示。

MHA 在自动切换的过程中会从宕掉的MySql master节点中保存二进制日志，以保证数据的完整性。但是如果master节点直接宕机了呢，或者网络直接不能联通了呢？MHA就没有办法获取master的二进制日志，也就没有办法保证数据的完整性了。这也就是为什么MHA应该与MySql主从复制结合起来。这样的话，只要有一个slave节点从master节点复制到了最新的日志，MHA就可以将最近的二进制日志应用到其他的slave节点上，这样就可以最大限度上保证数据的完整性。

MHA 自动切换的原理可以总结为下面几点.

从宕机崩溃的master保存二进制日志事件（binlog events）;

识别含有最新更新的slave;

应用差异的中继日志（relay log）到其他的slave;

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

提升一个slave为新的master;

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

MHA 工具组件

MHA 提供了很多的程序组件，通过这些组件，我们可以很方便的管理MHA集群。

Manager节点：

masterha_check_ssh：MHA依赖的环境监测工具;

masterha_check_ssh: MySql复制环境检测工具;

masterha_manager: MHA 服务主程序;

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

masterha_master_monitor: MySql master节点可用性检测工具;

masterha_switch: master 节点切换工具;

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

masterha_stop: 关闭MHA服务的工具;

Node节点:

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

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

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

实验介绍

在实际的生产环境中有很多的因素需要考虑，例如MHA Manager的单点问题。但是我们由于环境有限，所以就暂时不考虑这些。此次实验中实验环境如下。

担任角色主机名地址功能描述对应软件版本

MHA Manager manager 192.168.0.20 MHA Manager,控制Master节点故障转移 mha4mysql-manager-0.56-0.el6.noarch

MySql Master master 192.168.0.21 MySql Master 节点 Mariadb-server-5.5.56-2.el7

MySql Slave Slave1 192.168.0.22 Mysql Repliaction集群中的Slave1 节点 Mariadb-server-5.5.56-2.el7

MySql Slave Slave2 192.168.0.26 MySql Repliaction 集群中的Slave2节点 Mariadb-server-5.5.56-2.el7

担任角色	主机名	地址	功能描述	对应软件版本
MHA Manager	manager	192.168.0.20	MHA Manager,控制Master节点故障转移	mha4mysql-manager-0.56-0.el6.noarch
MySql Master	master	192.168.0.21	MySql Master 节点	Mariadb-server-5.5.56-2.el7
MySql Slave	Slave1	192.168.0.22	Mysql Repliaction集群中的Slave1 节点	Mariadb-server-5.5.56-2.el7
MySql Slave	Slave2	192.168.0.26	MySql Repliaction 集群中的Slave2节点	Mariadb-server-5.5.56-2.el7

准备MySql Replication 环境

安装PLUGIN

某种意义上说，Master节点不会一直充当master节点。Master节点从故障状态中恢复之后，很有可能充当的是slave节点，所以我们在安装插件的时候，不做区别对待。
mysql 支持多种插件/var/lib/mysql/plugin 目录下，需要安装方可使用。在Master(192.168.0.21)，和Slave(192.168.0.22,192.168.0.26)节点上安装semisync_master.so semisync_slave.so 两个插件。

MariaDB [(none)]> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
MariaDB [(none)]> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

然后在三台主机上开启下面两个参数

MariaDB [(none)]> SET GLOBAL rpl_semi_sync_master_enabled=ON;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SET GLOBAL rpl_semi_sync_slave_enabled=ON;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'rpl_semi%';
+------------------------------------+-------+
| Variable_name | Value |
+------------------------------------+-------+
| rpl_semi_sync_master_enabled | ON |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_no_slave | ON |
| rpl_semi_sync_slave_enabled | ON |
| rpl_semi_sync_slave_trace_level | 32 |
+------------------------------------+-------+
6 rows in set (0.00 sec)

到目前而言，三台主机之间没有差别，也没有角色上的区分。接下来我们开始设置master与slave来实现主从复制。

编辑 /etc/my.cnf.d/server.cnf 文件，加入下面这样一段配置

[mariadb]
server-id=1 #Master设置1，Slave1设置2，Slave2设置3
log-bin=mysql-bin
relay-log=mysql-relay-bin
relay_log_purge=0

修改完配置文件之后，重启Mariadb. systemctl restart mariadb

在master节点上进行操作

MariaDB [(none)]> GRANT REPLICATION MASTER ON *.* TO 'repl'@'%' IDENTIFIED BY '123';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

在slave节点上进行操作

MariaDB [(none)]> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY '123';
Query OK, 0 rows affected (0.01 sec)

MariaDB [(none)]> CHANGE MASTER TO
-> MASTER_HOST='192.168.0.21',
-> MASTER_PORT=3306,
-> MASTER_USER='repl',
-> MASTER_PASSWORD='123',
-> MASTER_LOG_FILE='mysql-bin.000001',
-> MASTER_LOG_POS=245;
Query OK, 0 rows affected (0.03 sec)

MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.00 sec)

上面的操作完成后，在master主机上查看master的状态。

MariaDB [(none)]> SHOW SLAVE HOSTS;
+-----------+------+------+-----------+
| Server_id | Host | Port | Master_id |
+-----------+------+------+-----------+
| 3 | | 3306 | 1 |
| 2 | | 3306 | 1 |
+-----------+------+------+-----------+

在slave主机上可以查看slave主机的状态。

*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.21
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 245
.............
.............
Slave_IO_Running: Yes
Save_SQL_Running: Yes
.............

在Master节点上创建MHA监控所需要的用户，该用户会同步到slave端。

MariaDB [(none)]> GRANT ALL PRIVILEGES ON *.* TO 'mha_rep'@'%' IDENTIFIED BY '123';

MariaDB [(none)]> flush privileges;

至此，MySql 主从复制环境就搭建好了。下面就可以开始来安装MHA了。

注：在查看slave节点状态时，如果出现问题，可以检查一下SELinux，iptables，以及其他权限问题，在实验开始之前，最好先将这些环境设置好，避免出现问题。

安装配置MHA

设置SSH免密通信

MHA 集群中的各节点之间需要基于SSH互相通信，以实现远程控制以及数据管理功能。简单起见，我们以Manager节点为例，然后将生成的文件发送到需要管理的主机上。四个节点都需要进行这个操作。

[root@manager ~]# ssh-keygen -t rsa
[root@manager ~]# for i in 21 22 26;do ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.0.$i; done

这样MHA Manager就实现了通过SSH免密管理其他的mysql节点

安装MHA

MHA 官方提供了rpm的安装包，通过搜索可以找到。CentOS 7 可以直接使用el6 的rpm安装包。下面是本次实验中rpm安装包的下载地址。https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads。

在所有节点上安装node安装包

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

在Manager节点上安装manager安装包

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

还可以在上述网站上下载源码包，里面有很多的例子和脚本可以直接拿来使用。将下载的源码包解压之后在samples/scripts下的所有脚本复制到/usr/bin目录(因为安装的mha manager的相关命令就在/usr/bin/目录下，可以使用rpm -ql mha4mysql-manager-0.56-0.el6 来查看)下。
脚本如下：

master_ip_failover #自动切换时vip管理的脚本，不是必须，如果我们使用keepalived的，我们可以自己编写脚本完成对vip的管理，比如监控mysql，如果mysql异常，我们停止keepalived就行，这样vip就会自动漂移
master_ip_online_change #在线切换时vip的管理，不是必须，同样可以可以自行编写简单的shell完成
power_manager #故障发生后关闭主机的脚本，不是必须
send_report #因故障切换后发送报警的脚本，不是必须，可自行编写简单的shell完成。

这里有一点需要注意，拷贝到/usr/bin 目录下的文件如果没有执行权限，要加上执行权限。

初始化MHA

Manager节点需要为每个监控的master/slave 集群提供专用的配置文件，而所有的master/slave集群也可以共享全局配置。全局配置文件默认在/etc/masterha_default.cnf，其为可选配置。如果仅监控一组master/slave集群，也可以直接通过application 的配置来提供给个服务器的默认配置信息。而灭个application的配置文件路径为自定义，我们的实例中，只有一个master/slave集群，所以我们就定义一个配置文件好了。

[root@manager ~]# cat /etc/masterha/app1.cnf

[server default]
manager_workdir=/etc/masterha
manager_log=/etc/masterha/manager.log
user=mha_rep
password=123
ping_interval=3
remote_workdir=/etc/masterha
repl_user=repl
repl_password=123
ssh_user=root
master_ip_failover_script=/usr/bin/master_ip_failover
master_ip_online_change_script=/usr/bin/master_ip_online_change
report_script=/usr/bin/send_report
shutdown_script=""
secondary_check_script=/usr/bin/masterha_secondary_check -s 192.168.0.22 -s 192.168.0.26 --user=root --master_host=192.168.0.21 --master_ip=192.168.0.21 --master_port=3306

[server1]
hostname=192.168.0.21
port=3306
master_binlog_dir=/var/lib/mysql/
candidate_master=1
check_repl_delay=0

[server2]
hostname=192.168.0.22
port=3306
master_binlog_dir=/var/lib/mysql/
candidate_master=1
check_repl_delay=0

[server3]
hostname=192.168.0.26
port=3306
master_binlog_dir=/var/lib/mysql/
no_master=1

编辑一下 /etc/masterha_default.cnf 文件，添加一些全局的配置。配置文件的内容如下。

[root@manager ~]# cat /etc/masterha_default.cnf

[server default]
user=mha_rep
password=123
repl_user=repl
repl_password=123
ssh_user=root
ping_interval=3
master_binlog_dir=/var/lib/mysql
remote_workdir=/etc/masterha
secondary_check_script=/usr/bin/masterha_secondary_check -s 192.168.0.22 -s 192.168.0.26 --user=root --master_host=192.168.0.21 --master_ip=192.168.0.21 --master_port=3306
# 设置自动failover时候的切换脚本;
master_ip_failover_script=/usr/bin/master_ip_failover
# 设置手动切换时候的切换脚本;
master_ip_online_change_script=/usr/bin/master_ip_online_change
# 设置发生切换后发送的报警的脚本;
report_script=/usr/bin/send_report
# 设置故障发生后关闭故障主机脚本（该脚本的主要作用是关闭主机防止发生脑裂,这里没有使用）;
shutdown_script=""

检查mysqlbinlog mysql 命令

在master，slave1 和slave2 节点上执行下面的命令检查一下mysqlbinlog和mysql 命令的位置。

[root@master ~]# type mysqlbinlog
mysqlbinlog is /usr/bin/mysqlbinlog
[root@master ~]# type mysql
mysql is /usr/bin/mysql

一定要确保 mysqlbinlog 和mysql 两个命令在 /usr/bin 目录下。由于我安装的是mariadb ，所以这两个文件默认就在这两个目录，如果是其他版本的mysql，不在这两个目录下的话可以使用软连接的方式，在这个目录下添加两个软连接。
否则，在进行检查的时候，会出现如下的类似错误。

mysqlbinlog

.....

Can't exec "mysqlbinlog": No suchfile or directory at /usr/local/share/perl5/MHA/BinlogManager.pm line 106.
mysqlbinlog version command failed with rc1:0, please verify PATH, LD_LIBRARY_PATH, and client options

.....

mysql

.....
Testing mysql connection and privileges..sh: mysql: command not found
mysql command failed with rc 127:0!
.....

配置VIP

在master 节点上进行操作，给ens33网卡添加一个VIP，这样用户访问的时候，就会可以通过VIP进行访问，并不需要关心MySQL集群中的具体细节。同时如果master宕机之后，VIP会自动进行转移，并不会影响到用户的访问，后端VIP漂移的过程对用户来说完全透明。

[root@manager ~]# ifconfig ens33:1 192.168.0.88

在MHA manager上进行操作，修改/usr/bin/master_ip_failover脚本如下，主要是VIP的修改。

[root@centos7-1 ~]# cat /usr/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 $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";
# 这一行很重要，表示在master上mysql服务停止之后，关闭掉VIP，以免地址冲突
&stop_vip();
&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";
}

验证MHA

经过上述的一系列的的配置和操作，我们就顺利的配置好了MySql replication 环境和MHA 环境，接下来开始验证一下。
在MHA manager 上进行一下下面的操作。

# 检测主机之间的SSH 联通性
[root@manager ~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf
.....
# 省略了很多非关键信息出现类似下面的 successfully 表示SSH 联通性检测成功
Sun Jan 14 20:09:30 2018 - [info] All SSH connection tests passed successfully.

# 检测mysql 复制集群的配置参数是否正确
[root@manager ~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf

.......

# 可以看到我们配置的master/slave信息
192.168.0.21(192.168.0.21:3306) (current master)
+--192.168.0.22(192.168.0.22:3306)
+--192.168.0.26(192.168.0.26:3306)

.....

# 省略了很多非必要信息，出现下面的Health is OK ，说明主从复制检测成功
MySQL Replication Health is OK.

启动MHA

在manager 节点上进行操作。

[root@manager ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1 &
[1] 7861
[root@manager ~]# masterha_check_status --conf=/etc/masterha/app1.cnf
app1 (pid:7861) is running(0:PING_OK), master:192.168.0.21

停止MHA

如果想要停止MHA 可以执行如下的命令

[root@manager ~]# masterha_stop --conf=/etc/masterha/app1.cnf
Stopped app1 successfully.
[1]+ Exit 1 nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1

MHA 测试故障转移

在master节点关闭mariadb 服务

systemctl stop mariadb

在Manager 节点查看/etc/masterha/manager.log

在manager节点查看 manager.log 的日志，可以看到下面的切换过程

----- Failover Report -----

app1: MySQL Master failover 192.168.0.21(192.168.0.21:3306) to 192.168.0.22(192.168.0.22:3306) succeeded

Master 192.168.0.21(192.168.0.21:3306) is down!

Check MHA Manager logs at manager:/etc/masterha/manager.log for details.

Started automated(non-interactive) failover.
Invalidated master IP address on 192.168.0.21(192.168.0.21:3306)
The latest slave 192.168.0.22(192.168.0.22:3306) has all relay logs for recovery.
Selected 192.168.0.22(192.168.0.22:3306) as a new master.
192.168.0.22(192.168.0.22:3306): OK: Applying all logs succeeded.
192.168.0.22(192.168.0.22:3306): OK: Activated master IP address.
192.168.0.26(192.168.0.26:3306): This host has the latest relay log events.
Generating relay diff files from the latest slave succeeded.
192.168.0.26(192.168.0.26:3306): OK: Applying all logs succeeded. Slave started, replicating from 192.168.0.22(192.168.0.22:3306)
192.168.0.22(192.168.0.22:3306): Resetting slave info succeeded.
Master failover to 192.168.0.22(192.168.0.22:3306) completed successfully.

注意，故障转移完成之后，manager会自动停止，此时使用masterha_check_status命令检测将会是下面这种结果.

[root@manager ~]# masterha_check_status --conf=/etc/masterha/app1.cnf
app1 is stopped(2:NOT_RUNNING).

在新的Master上进行验证

在新的master主机slave1上进行查看,master_id 已经进行了切换，并且少了一台slave 主机。

在slave2主机上查看slave 的当前状态。

MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.22
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 384
Relay_Log_File: mysql-relay-bin.000002
Relay_Log_Pos: 529
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

.......................

可以看到最新的master的IP 已经变成了之前slave1 主机的IP地址，这说明master 切换成功。

在新Master主机上查看VIP迁移，旧master主机上查看IP

在新的master 主机上查看ip地址的变化,如果VIP 漂移成功说明，之前的配置没有问题。

[root@slave1 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:50:56:37:c4:5e brd ff:ff:ff:ff:ff:ff
inet 192.168.0.88/24 brd 192.168.0.255 scope global ens33:1
valid_lft forever preferred_lft forever
inet 192.168.0.22/24 brd 192.168.0.255 scope global secondary dynamic ens33
valid_lft 6390sec preferred_lft 6390sec
inet6 fe80::e9cb:24a6:f81d:1810/64 scope link
valid_lft forever preferred_lft forever

在旧的master主机上查看VIP是否已经被移除。

[root@master ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:50:56:29:d0:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.0.21/24 brd 192.168.0.255 scope global dynamic ens33
valid_lft 7198sec preferred_lft 7198sec
inet6 fe80::c28a:e648:5959:5ad6/64 scope link
valid_lft forever preferred_lft forever

如果上面两项的检测都没有问题，说明在实际的使用过程中VIP 就不会产生地址冲突了。而且地址切换过程对用户来说，基本上没有任何感知，这样就保证了mysql服务的高可用了。

抢救故障节点，重新加入集群

生产中mysql服务停掉可以立即监监控到，而且这基本上属于以及故障需要立即进行排除。
重新恢复宕掉的mysql服务比较好的思路是，将其基于最新的master节点的数据备份进行数据恢复，然后重新启动服务，将其设置为slave节点，并加入到新的master集群，之后重启MHA监控。
备份还原过程，此处不再赘述。将启动后的节点重新加入到新的master集群中。过程与之前介绍的类似。

MariaDB [(none)]> CHANGE MASTER TO
-> MASTER_HOST='192.168.0.22',
-> MASTER_PORT=3306,
-> MASTER_USER='repl',
-> MASTER_PASSWORD='123',
-> MASTER_LOG_FILE='mysql-bin.000004',
-> MASTER_LOG_POS=384;
Query OK, 0 rows affected (0.01 sec)

MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.00 sec)

在新的master节点上查看最新的slave主机状态。

MariaDB [(none)]> show slave hosts;
+-----------+------+------+-----------+
| Server_id | Host | Port | Master_id |
+-----------+------+------+-----------+
| 1 | | 3306 | 2 |
| 3 | | 3306 | 2 |
+-----------+------+------+-----------+
2 rows in set (0.00 sec)

可以看到slave 主机的server_id 已经变化了。

在manager主机上检查MHA

在manager上修改/etc/masterha/app1.cnf中secondary_check_script中的master IP值，将新的master ip修改上

secondary_check_script=/usr/bin/masterha_secondary_check -s 192.168.0.21 -s 192.168.0.26 --user=root --master_host=192.168.0.22 --master_ip=192.168.0.22 --master_port=3306

修改/etc/masterha_default.cnf 中secondary_check_script 中的IP地址

secondary_check_script=/usr/bin/masterha_secondary_check -s 192.168.0.21 -s 192.168.0.26 --user=root --master_host=192.168.0.22 --master_ip=192.168.0.22 --master_port=3306

在Manager 上启动MHA 然后检查MHA的状态

[root@centos7-1 ~]# masterha_check_repl --conf=/etc/masterha/app1.cnf

.........

192.168.0.22(192.168.0.22:3306) (current master)
+--192.168.0.21(192.168.0.21:3306)
+--192.168.0.26(192.168.0.26:3306)

......

MySQL Replication Health is OK.

启动MHA ，检查MHA的状态

[root@manager ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1 &
[1] 9186
[root@manager ~]# masterha_check_status --conf=/etc/masterha/app1.cnf
app1 (pid:9186) is running(0:PING_OK), master:192.168.0.22

总结

至此，MySql MHA 的配置与测试基本就完成了。在实际生产中，至少也应该对MySQL主从复制进行一下验证，并且对MySQL 故障进行了解，以便在实际生产中能够有效的排除故障。

本文转自Eumenides_s 51CTO博客，原文链接：
http://blog.51cto.com/xiaoshuaigege/2060768
，如需转载请自行联系原作者

Step By Step 搭建 MySql MHA 集群

关于MHA

MHA Manager 和 MHA Node

MHA 工具组件

实验介绍

准备MySql Replication 环境

安装PLUGIN

安装配置MHA

设置SSH免密通信

安装MHA

初始化MHA

检查mysqlbinlog mysql 命令

配置VIP

验证MHA

启动MHA

在manager 节点上进行操作。

`[root@manager ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1 & [1] 7861 [root@manager ~]# masterha_check_status --conf=/etc/masterha/app1.cnf app1 (pid:7861) is running(0:PING_OK), master:192.168.0.21`

停止MHA

如果想要停止MHA 可以执行如下的命令

`[root@manager ~]# masterha_stop --conf=/etc/masterha/app1.cnf Stopped app1 successfully. [1]+ Exit 1 nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1`

MHA 测试故障转移

在master节点关闭mariadb 服务

`systemctl stop mariadb`

在Manager 节点查看/etc/masterha/manager.log

在新的Master上进行验证

在新Master主机上查看VIP迁移，旧master主机上查看IP

抢救故障节点，重新加入集群

在manager主机上检查MHA

总结

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

Step By Step 搭建 MySql MHA 集群

关于MHA

MHA Manager 和 MHA Node

MHA 工具组件

实验介绍

准备MySql Replication 环境

安装PLUGIN

安装配置MHA

设置SSH免密通信

安装MHA

初始化MHA

检查mysqlbinlog mysql 命令

配置VIP

验证MHA

启动MHA

在manager 节点上进行操作。 [root@manager ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1 & [1] 7861 [root@manager ~]# masterha_check_status --conf=/etc/masterha/app1.cnf app1 (pid:7861) is running(0:PING_OK), master:192.168.0.21

停止MHA

如果想要停止MHA 可以执行如下的命令 [root@manager ~]# masterha_stop --conf=/etc/masterha/app1.cnf Stopped app1 successfully. [1]+ Exit 1 nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1

MHA 测试故障转移

在master节点关闭mariadb 服务

systemctl stop mariadb

在Manager 节点查看/etc/masterha/manager.log

在新的Master上进行验证

在新Master主机上查看VIP迁移，旧master主机上查看IP

抢救故障节点，重新加入集群

在manager主机上检查MHA

总结

热门文章

最新文章

相关课程

相关电子书

相关实验场景

推荐镜像

在manager 节点上进行操作。

`[root@manager ~]# nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1 & [1] 7861 [root@manager ~]# masterha_check_status --conf=/etc/masterha/app1.cnf app1 (pid:7861) is running(0:PING_OK), master:192.168.0.21`

如果想要停止MHA 可以执行如下的命令

`[root@manager ~]# masterha_stop --conf=/etc/masterha/app1.cnf Stopped app1 successfully. [1]+ Exit 1 nohup masterha_manager --conf=/etc/masterha/app1.cnf < /dev/null > /etc/masterha/manager.log 2>&1`

`systemctl stop mariadb`