大家都知道,任何线上环境,都必须搭载高可用架构,是web的,也要是数据库的,严格来说更是整个架构的高可用.
mysql作为时下比较热的数据库,高可用架构更加需求大.不过,以前老旧那一套已经不合时宜,现在用的比较多的就是MHA和PXC了.
PXC的优势是做到同写同回滚,达到数据高度一致性,通过一些程序和代码来做第三方分发,可以做到一定程度的读写分离,是个相当不错的高可用解决方案,不过对网络要求比较高,配置也略复杂一些,最好是同一个机房里面做,不过这并不是本文重点,后面找时间再写相关的文章.
本文要说的就是MHA,版本是0.56,先介绍一下,它由日本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服务器上，因此可以保证所有节点的数据一致性,还有一种方法就是binlog server,因为binlog server不用回写mysql数据库,速度往往比较快,丢数据的风险也低很多,怎么搭建binlog server可以看我另一篇文章。
我们来看看mha的工作原理:
（1）从宕机崩溃的master保存二进制日志事件（binlog events）(包括binlog server);
（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的核心功能就是数据库的故障切换,原则上不会去做其他事情,其他额外功能(例如切换vip什么的),是要通过第三方软件(例如keepalived)或者是脚本来实现的,要区分清楚,所以配置上是可以忽略警告来做的,因为不是必须的.
第二,MHA每次故障切换完都会退出,原主库起来后还需要手动去补全数据和操作变成从库,然后从新开启MHA来使用,开启后再通过手动切换回原主库,手动切换不会退出MHA,不过切换还是需要谨慎一些.
安装MHA-0.56
打了那么多字,现在来转回正题,先说怎么安装的问题.
安装前要先做一个主从结构,至于怎么做主从我就不在这里再演示了,有兴趣的可以看我另一篇文章,在线做主从,其实很简单.
装完主从就开始装MHA了,我们把node端装到主库,把Manager装在从库,这样安装的目的也显而易见,当你主库服务器down机了,Manager都被强制关闭了,你还怎么切是吧,所以必须是装在从库.
我们依然先安装一个epel库
rpm -Uvh http://mirrors.kernel.org/fedora-epel/6/i386/epel-release-6-8.noarch.rpm
然后yum一些依赖包
yum install -y perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager
然后下载MHA-0.56,想要原版,那就要去翻 墙下载,
https://code.google.com/p/mysql-master-ha/wiki/Downloads
如果你信得过我,那就进入下面这个连接吧,
http://down.51cto.com/data/2227241
有RPM和源码版,看你喜欢,我比较懒,所以我用RPM版,不过要注意哦,貌似RPM版是rhel和centos专用的.
安装Manager前还得必须先装node,比较奇葩.那么干脆都装上去.
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm
只要依赖库没问题,安装就不会有问题,非常简单,如果你是要装源码版,就麻烦一点,功能是一样的,而且还多一些配置文件模板给你用,其实也还行.
安装node端
tar xf mha4mysql-node-0.53.tar.gz
cd mha4mysql-node-0.53
perl Makefile.PL
make && make install
安装manger端
tar xf mha4mysql-manager-0.53.tar.gz
cd mha4mysql-manager-0.53
perl Makefile.PL
make && make install
然后我们看看安装情况,因为严格来说MHA是一套perl脚本命令操作的,所以安装的本质其实就是把命令执行文件解压,
ll /usr/bin
-r-xr-xr-x 1 root root 15498 Apr 20 10:58 apply_diff_relay_logs -r-xr-xr-x 1 root root 4807 Apr 20 10:58 filter_mysqlbinlog -r-xr-xr-x 1 root root 1995 Apr 20 11:33 masterha_check_repl -r-xr-xr-x 1 root root 1779 Apr 20 11:33 masterha_check_ssh -r-xr-xr-x 1 root root 1865 Apr 20 11:33 masterha_check_status -r-xr-xr-x 1 root root 3201 Apr 20 11:33 masterha_conf_host -r-xr-xr-x 1 root root 2517 Apr 20 11:33 masterha_manager -r-xr-xr-x 1 root root 2165 Apr 20 11:33 masterha_master_monitor -r-xr-xr-x 1 root root 2373 Apr 20 11:33 masterha_master_switch -r-xr-xr-x 1 root root 3749 Apr 20 11:33 masterha_secondary_check -r-xr-xr-x 1 root root 1739 Apr 20 11:33 masterha_stop -r-xr-xr-x 1 root root 7401 Apr 20 10:58 purge_relay_logs -r-xr-xr-x 1 root root 7263 Apr 20 10:58 save_binary_logs
到这里,MHA就算安装完成了,仅仅只是安装完成.
然后,来看配置MHA架构
MHA在配置方面有点坑,为什么这么说了,原因是很多配置并没有明示,需要自己去摸索和借鉴参考,如果你是用rpm安装的,甚至没有配置模板,全部都要自己写,相当蛋疼,而且虽然说支持第三方应用和脚本,也是需要额外配置,例如网上有很多借用keepalived来切换vip的方法的文档,我就不多说了,这里我说的是全部都用脚本来实现的切换,包括vip,不使用其他第三方应用.
首先我们来做些前期工作,先完成一个完整的mysql主从架构并修改一些配置和手动加上vip,还有ssh的免密钥处理(复制binlog或relaylog用),MHA第一次启动不会自己绑定VIP,所以需要自己来做,不用很复杂,一条命令就可以了,当然了,你可以更复杂一些,也更严谨一些.
ifconfig eth1:1 10.0.2.101/24
这个时候你的应用或客户端就可以通过这个vip来连接数据库了,当然了,这是内网IP.
一些mysql的前期工作:
怎么完成一个完整的mysql主从架构,大家可以看我另一篇文章,我不想文章篇幅太长就不多说了,这里只说几个重点.
第一,数据库的复制和管理的授权要做好,不只是当前的主从授权,也要考虑到切换后的主从授权,因为故障切换后,现在的主就是切换后的从,如果没有授权,就写不进数据了,特别要注意三台,四台组成的架构.
第二,从库尽量设置成只读,避免某些应用或客户端误写入数据,特别是切换后特别容易出现这种情况.这个可以手动更改,也是比较方便的,切换的时候mha也会自动设置回可写.
mysql -uroot -p‘******‘ -e "set global read_only=1"
第三,把relay log的自动清除设置关闭了,因为在多台数据库实例结合的MHA架构中,MHA会主动校对那一个实例的binlog和relay log比较新,然后把这些最新的数据应用到候选主库上,然后再切换完成.
mysql -uroot -p‘******‘ -e "set global relay_log_purge=0"
当然了,关闭了之后,随之而来的就是relay log会不断增长,导致最终撑爆硬盘,这是不允许的,所以我们需要有个清理机制,最后就有了利用脚本加上计划任务定期清理的方法.
主要方法是利用MHA的自带命令:
/usr/bin/purge_relay_logs
参数说明:
--user mysql 用户名
--password mysql 密码
--port 端口号
--workdir 指定创建relay log的硬链接的位置，默认是/var/tmp，由于系统不同分区创建硬链接文件会失败，故需要执行硬链接具体位置，成功执行脚本后，硬链接的中继日志文件被删除
--disable_relay_log_purge 默认情况下，如果relay_log_purge=1，脚本会什么都不清理，自动退出，通过设定这个参数，当relay_log_purge=1的情况下会将relay_log_purge设置为0。清理relay log之后，最后将参数设置为OFF。
然后脚本如下:
#!/bin/bash
user=root
passwd=123123
port=3306
log_dir=‘/data/masterha/log‘
work_dir=‘/data/mysql/data/‘
purge=‘/usr/bin/purge_relay_logs‘
if [ ! -d $log_dir ]
then
mkdir $log_dir -p
fi
$purge --user=$user --password=$passwd --disable_relay_log_purge --port=$port --workdir=$work_dir >> $log_dir/purge_relay_logs.log 2>&1
最后加入到计划任务:
crontab -l
0 4 * * * /bin/bash /root/purge_relay_log.sh
好了,mysql的准备工作完成了,继续走下去.
设置MHA架构间的SSH密钥,使其免密码登陆,刚才我也有说过了,MHA会通过校对binlog和relay log,将最新的数据放到候选主库,这期间就必然有数据传输的需求,所以也就需要SSH的免密码登陆了.
方法很简单,网上资料多如牛毛,我就简单说一下就算了.
先使用命令:
ssh-keygen
一路回车就好了,不用想太多,然后在/root/.ssh/下面得到两个文件id_rs,id_rsa.pub,
然后生成信任文件:
cd /root/.ssh/
cat id_rsa.pub >authorized_keys
顺便也设置权限,
chmod 600 ./*
然后复制到目标机器,所有MHA相关的服务器
scp -P 22 -o StrictHostKeyChecking=no ./* [email protected]:/root/.ssh/
然后尝试登陆并成功就完成了.
准备工作就这样做完了,然后来正式转入正题,配置MHA环境
首先要说的是,MHA并没要求配置文件具体放那个位置,所以这个并不固定,然后也正如我一开始说的,如果你用rpm安装,甚至没有配置文件模板,所以下面我会贴出来给大家参考,大家就不用找得那么辛苦了.
然后配置文件有两种:
全局配置文件,名字可以改,我这里是默认模板的:
masterha_default.cnf
还有独立MHA的配置文件,名字可以改,我这里也是默认模板:
app1.cnf
他这个目的是考虑到manger可能是独立的服务器,所以是可以运行多个manger的,不同的配置文件就代表运行不同的manger,也就是控制着不同的MHA架构,而不同的MHA架构也可能存在相同的全局配置,所以配置文件就这么多样化了,实际上是可以把所有配置都写到app1.cnf这个独立配置文件里面的,并不影响使用.
而我的设置就如下,供大家参考,以下是:
cat masterha_default.cnf
[server default]
#mysql用户和密码
user=root
password=123123
#系统登陆ssh用户
ssh_user=root
#复制用户
repl_user=root
repl_password=123123
#binlog路径,master 保存binlog的位置，以便MHA可以找到master的日志，我这里的也就是mysql的数据目录
master_binlog_dir= /var/lib/mysql,/var/log/mysql,/data/mysql/data
#远端mysql在发生切换时binlog的保存位置
remote_workdir=/data/log/masterha
#监控主库，发送ping包的时间间隔，默认是3秒，尝试三次没有回应的时候自动进行railover
ping_interval=1
#通过第三方机器确认目标主库是否存活,不是必须的,就算没有也是能用
#secondary_check_script= masterha_secondary_check -s remote_host1 -s remote_host2
#故障发生后关闭主机的脚本,不是必须的,但是你要设置为空
# shutdown_script= /usr/local/masterha/scripts/power_manager
shutdown_script=""
#故障自动切换VIP调用脚本,不是必须的,就算没有也是能用,如果你有keepalived这种来做切换VIP就可以直接不用了
master_ip_failover_script=/usr/local/masterha/scripts/master_ip_failover
#报告发送脚本,不是必须的,就算没有也是能用
# report_script= /usr/local/masterha/scripts/send_report
#手动在线切换VIP脚本,不是必须的,就算没有也是能用,如果你有keepalived这种来做切换VIP就可以直接不用了
master_ip_online_change_script=/usr/local/masterha/scripts/master_ip_online_change
然后是另外一个配置文件,我们假设有三个节点,server1是主节点,一个server2是候选节点,一个server3是管理节点:
cat app1.cnf
[server default]
#manager的工作目录
manager_workdir=/var/log/masterha/app1
#manager的日志
manager_log=/var/log/masterha/app1/manager.log
#当前主节点
[server1]
#数据库地址
hostname=10.0.2.5
#数据库端口
port=3306
#ssh的端口
ssh_port=22
#当前候选节点
[server2]
hostname=10.0.2.6
port=3306
ssh_port=22
#设置为候选master，如果设置该参数以后，发生主从切换以后将会将优先此从库提升为主库，即使这个主库不是集群中事件最新的slave
candidate_master=1
#默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master,一定程度上也是可以加快切换的参数
check_repl_delay=0
#当前管理节点
[server3]
hostname=10.0.2.7
port=3306
ssh_port=22
#如果这个节点挂了，mha将不可用，加上这个参数，这个slave挂了一样可以用
ignore_fail=1
#从不将这台主机转换为master
no_master=1
也正如我刚才说的那样,你可以把上面两个配置文件都写到一个文件里面,例如都写进app1.cnf,一样可以正常使用,后面会再详细说说怎么使用.
然后说说那些用来切换的脚本,
master_ip_failover
master_ip_online_change
send_report
因为我不是很懂perl,所以并不清楚安装完MHA自带的脚本为什么不能用,不过经过搜索查找到别人的脚本,经过证实是可以用的,下面来一个个看.
这个是master_ip_failover
主要需要修改vip,有额外情况,可能需要更改key,ssh_start_vip,ssh_stop_vip,主要是看你的vip命名规则
cat 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 = ‘10.0.2.101/24‘; # Virtual IP
my $key = "1";
my $ssh_start_vip = "/sbin/eth1:$key $vip";
my $ssh_stop_vip = "/sbin/eth1:$key down";
my $exit_code = 0;
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" ) {
# $orig_master_host, $orig_master_ip, $orig_master_port are passed.
# If you manage master ip address at global catalog database,
# invalidate orig_master_ip here.
my $exit_code = 1;
eval {
print "\n\n\n***************************************************************\n";
print "Disabling the VIP - $vip on old master: $orig_master_host\n";
print "***************************************************************\n\n\n\n";
&stop_vip();
$exit_code = 0;
};
if ([email protected]) {
warn "Got Error: [email protected]\n";
exit $exit_code;
}
exit $exit_code;
}
elsif ( $command eq "start" ) {
# all arguments are passed.
# If you manage master ip address at global catalog database,
# activate new_master_ip here.
# You can also grant write access (create user, set read_only=0, etc) here.
my $exit_code = 10;
eval {
print "\n\n\n***************************************************************\n";
print "Enabling the VIP - $vip on new master: $new_master_host \n";
print "***************************************************************\n\n\n\n";
&start_vip();
$exit_code = 0;
};
if ([email protected]) {
warn [email protected];
exit $exit_code;
}
exit $exit_code;
}
elsif ( $command eq "status" ) {
print "Checking the Status of the script.. OK \n";
`ssh $ssh_user\@$orig_master_host \" $ssh_start_vip \"`;
exit 0;
}
else {
&usage();
exit 1;
}
}
# A simple system call that enable the VIP on the new master
sub start_vip() {
`ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
# A simple system call that disable the VIP on the old_master
sub stop_vip() {
`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=po
rt –new_master_host=host –new_master_ip=ip –new_master_port=port\n";
}
然后这个是master_ip_online_change
和上面一样,主要需要修改vip,有额外情况,可能需要更改key,ssh_start_vip,ssh_stop_vip,主要是看你的vip命名规则
cat master_ip_online_change
#!/usr/bin/env perl
use strict;
use warnings FATAL =>‘all‘;
use Getopt::Long;
my $vip = ‘10.0.2.101/24‘; # Virtual IP
my $key = "1";
my $ssh_start_vip = "/sbin/eth1:$key $vip";
my $ssh_stop_vip = "/sbin/eth1:$key down";
my $exit_code = 0;
my (
$command, $orig_master_is_new_slave, $orig_master_host,
$orig_master_ip, $orig_master_port, $orig_master_user,
$orig_master_password, $orig_master_ssh_user, $new_master_host,
$new_master_ip, $new_master_port, $new_master_user,
$new_master_password, $new_master_ssh_user,
);
GetOptions(
‘command=s‘ => \$command,
‘orig_master_is_new_slave‘ => \$orig_master_is_new_slave,
‘orig_master_host=s‘ => \$orig_master_host,
‘orig_master_ip=s‘ => \$orig_master_ip,
‘orig_master_port=i‘ => \$orig_master_port,
‘orig_master_user=s‘ => \$orig_master_user,
‘orig_master_password=s‘ => \$orig_master_password,
‘orig_master_ssh_user=s‘ => \$orig_master_ssh_user,
‘new_master_host=s‘ => \$new_master_host,
‘new_master_ip=s‘ => \$new_master_ip,
‘new_master_port=i‘ => \$new_master_port,
‘new_master_user=s‘ => \$new_master_user,
‘new_master_password=s‘ => \$new_master_password,
‘new_master_ssh_user=s‘ => \$new_master_ssh_user,
);
exit &main();
sub main {
#print "\n\nIN SCRIPT TEST====$ssh_stop_vip==$ssh_start_vip===\n\n";
if ( $command eq "stop" || $command eq "stopssh" ) {
# $orig_master_host, $orig_master_ip, $orig_master_port are passed.
# If you manage master ip address at global catalog database,
# invalidate orig_master_ip here.
my $exit_code = 1;
eval {
print "\n\n\n***************************************************************\n";
print "Disabling the VIP - $vip on old master: $orig_master_host\n";
print "***************************************************************\n\n\n\n";
&stop_vip();
$exit_code = 0;
};
if ([email protected]) {
warn "Got Error: [email protected]\n";
exit $exit_code;
}
exit $exit_code;
}
elsif ( $command eq "start" ) {
# all arguments are passed.
# If you manage master ip address at global catalog database,
# activate new_master_ip here.
# You can also grant write access (create user, set read_only=0, etc) here.
my $exit_code = 10;
eval {
print "\n\n\n***************************************************************\n";
print "Enabling the VIP - $vip on new master: $new_master_host \n";
print "***************************************************************\n\n\n\n";
&start_vip();
$exit_code = 0;
};
if ([email protected]) {
warn [email protected];
exit $exit_code;
}
exit $exit_code;
}
elsif ( $command eq "status" ) {
print "Checking the Status of the script.. OK \n";
`ssh $orig_master_ssh_user\@$orig_master_host \" $ssh_start_vip \"`;
exit 0;
}
else {
&usage();
exit 1;
}
}
# A simple system call that enable the VIP on the new master
sub start_vip() {
`ssh $new_master_ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
# A simple system call that disable the VIP on the old_master
sub stop_vip() {
`ssh $orig_master_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=po
rt –new_master_host=host –new_master_ip=ip –new_master_port=port\n";
}
然后来看send_report,其实系统自带的send_report是能用的,问题是他只能发往服务器系统默认的邮箱,实际上大部分人都不会设那东西,所以就等于没用了.
这个脚本要改的也就是邮箱的信息了,smtp,mail_from,mail_user,mail_pass,mail_to,改完就可以了.
cat send_report
#!/usr/bin/perl
use strict;
use warnings FATAL => ‘all‘;
use Mail::Sender;
use Getopt::Long;
#new_master_host and new_slave_hosts are set only when recovering master succeeded
my ( $dead_master_host, $new_master_host, $new_slave_hosts, $subject, $body );
my $smtp=‘smtp.163.com‘;
my $mail_from=‘xxxx‘;
my $mail_user=‘xxxxx‘;
my $mail_pass=‘xxxxx‘;
my $mail_to=[‘xxxx‘,‘xxxx‘];
GetOptions(
‘orig_master_host=s‘ => \$dead_master_host,
‘new_master_host=s‘ => \$new_master_host,
‘new_slave_hosts=s‘ => \$new_slave_hosts,
‘subject=s‘ => \$subject,
‘body=s‘ => \$body,
);
mailToContacts($smtp,$mail_from,$mail_user,$mail_pass,$mail_to,$subject,$body);
sub mailToContacts {
my ( $smtp, $mail_from, $user, $passwd, $mail_to, $subject, $msg ) = @_;
open my $DEBUG, "> /tmp/monitormail.log"
or die "Can‘t open the debug file:$!\n";
my $sender = new Mail::Sender {
ctype => ‘text/plain; charset=utf-8‘,
encoding => ‘utf-8‘,
smtp => $smtp,
from => $mail_from,
auth => ‘LOGIN‘,
TLS_allowed => ‘0‘,
authid => $user,
authpwd => $passwd,
to => $mail_to,
subject => $subject,
debug => $DEBUG
};
$sender->MailMsg(
{ msg => $msg,
debug => $DEBUG
}
) or print $Mail::Sender::Error;
return 1;
}
# Do whatever you want here
exit 0;
好了,万事俱备只欠东风,剩下的,就是准备启动了.
启动MHA
准备启动前,还是要检测一下,MHA自带了检测命令,非常好用.
其中,global_conf指定全局配置文件,conf指定特定配置文件,如果你全部都写进了app1.cnf,那就不需要写global_conf了.
先检查下服务器之间SSH是否都正常
masterha_check_ssh --global_conf=/usr/local/masterha/conf/masterha_default.cnf --conf=/usr/local/masterha/conf/app1.cnf
看到OK和下面这句
All SSH connection tests passed successfully.
就没问题了.
然后检查一下整个架构的主从是否正常,这将决定这个架构是否能启动MHA成功
masterha_check_repl --global_conf=/usr/local/masterha/conf/masterha_default.cnf --conf=/usr/local/masterha/conf/app1.cnf
这条结果可能有点特别,因为不排除有warning,但是并不影响使用,看到error那才是要解决的,主要就是要看这个就可以了.
MySQL Replication Health is OK.
而使用keepalived这类来做切换vip的朋友,因为屏蔽了使用
master_ip_failover
master_ip_online_change
所以会出现
[warning] master_ip_failover_script is not defined.
[warning] shutdown_script is not defined
但都是正常的,不代表有问题,可以放心使用.
再然后,我们来检查下当前状态
masterha_check_status --global_conf=/usr/local/masterha/conf/masterha_default.cnf --conf=/usr/local/masterha/conf/app1.cnf
app1 is stopped(2:NOT_RUNNING).
不要紧张,是正常的呢,因为都没启动嘛,所以当然是NOT_RUNNING
现在开始启动MHA的进程
masterha_manager --global_conf=/usr/local/masterha/conf/masterha_default.cnf --conf=/usr/local/masterha/conf/app1.cnf > /tmp/mha_manager.log 2>&1 &
介绍几个比较有用的参数
启动参数介绍：
--remove_dead_master_conf 该参数代表当发生主从切换后，老的主库的ip将会从配置文件中移除。
--manger_log 日志存放位置,想规范化管理日志可以加上
--ignore_last_failover 该参数代表忽略上次MHA触发切换产生的文件，默认情况下，MHA发生切换后会在日志目录，也就是上面我设置的/data产生app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，在缺省情况下，如果MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failover，之所以这样限制是为了避免ping-pong效应。
再检查下当前状态
masterha_check_status --global_conf=/usr/local/masterha/conf/masterha_default.cnf --conf=/usr/local/masterha/conf/app1.cnf
app1 (pid:20386) is running(0:PING_OK), master:****
启动完毕,也显示正常,我们也可以看看日志,看到
Ping(SELECT) succeeded, waiting until MySQL doesn‘t respond..
说明整个系统已经开始监控了.
有启动就有关闭,下面这个就是关闭命令
masterha_stop --global_conf=/usr/local/masterha/conf/masterha_default.cnf --conf=/usr/local/masterha/conf/app1.cnf
不会返回什么特别的东西,一般都会关闭成功.
剩下的就是测试怎么故障恢复了,这里就不细说了,各位可以自己试试.