部署过程
主从环境准备
首先先搭建一主两从GTID复制环境,此处不赘述
配置关键程序软链接
(所有节点均执行)
ln -s /data/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /data/mysql/bin/mysql /usr/bin/mysql
配置各节点互信
db01:
rm -rf /root/.ssh
ssh-keygen
cd /root/.ssh
mv id_rsa.pub authorized_keys
scp -r /root/.ssh 10.0.0.52:/root
scp -r /root/.ssh 10.0.0.53:/root
各节点验证
db01:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
db02:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
db03:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
或常用:
(1)生成本机的公钥:
ssh-keygen (只需要生成一个公钥就行所以只输入一次)
#当你在生成sshkey的时候在命令行下会提示你Enter file in which to save the key,让你确认密钥文件保存的路径,
一般回车即可(一般默认会在当前用户家目录下的.ssh目录下)。
#第二个提示是 Enter passphrase (empty for no passphrase) 让你输入一个密钥的密码,
如果不输入则留空;回车生成公钥完毕 😃
此时你可以使用cat命令看下自己的公私钥。
(2)ssh-copy-id复制公钥:
yum -y install openssh-clients
ssh-copy-id x.x.x.x (需要做ssh登陆的服务器ip)
#它会将本地的所有公钥都传到服务器
(3)复制完后输入exit退出ssh登陆
(4)使用ssh登陆:
ssh x.x.x.x (需要做ssh登陆的服务器ip)
(注:连自己本机也要配置)
安装软件
Manager工具包主要包括以下几个工具:
masterha_manger 启动MHA
masterha_check_ssh 检查MHA的SSH配置状况
masterha_check_repl 检查MySQL复制状况
masterha_master_monitor 检测master是否宕机
masterha_check_status 检测当前MHA运行状态
masterha_master_switch 控制故障转移(自动或者手动)
masterha_conf_host 添加或删除配置的server信息
Node工具包主要包括以下几个工具:
这些工具通常由MHA Manager的脚本触发,无需人为操作
save_binary_logs 保存和复制master的二进制日志
apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs 清除中继日志(不会阻塞SQL线程)
mha官网:
https://code.google.com/archive/p/mysql-master-ha/
github下载地址:
https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads
可能已经失效了,需要用之前的包
所有节点都安装node软件依赖包
先解压上传的压缩包
然后
yum install perl-DBD-MySQL -y
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
在db01主库中创建mha需要的用户
grant all privileges on *.* to mha@'10.0.0.%' identified by 'mha';
如果主从是好的,则在主库创建完用户,会直接同步到从库
如果进行更精确的授权,参考如下最小授权:
GRANT RELOAD, SUPER, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'mha'@'%';
GRANT SELECT ON `mysql`.* TO 'mha'@'%'
Manager软件安装(db03)
yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm
Manager配置文件准备(db03)
创建配置文件目录
mkdir -p /etc/mha
创建日志目录
mkdir -p /var/log/mha/app1
编辑mha配置文件
vim /etc/mha/app1.cnf
或者
cat > /etc/mha/app1.cnf &1 &
注:
masterha_manager就是启动manager程序的,配置文件指向我们之前配好的文件
执行完命令后敲几下回车
查看MHA状态
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:4719) is running(0:PING_OK), master:10.0.0.51
[root@db03 ~]# mysql -umha -pmha -h 10.0.0.51 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 51 |
+---------------+-------+
[root@db03 ~]# mysql -umha -pmha -h 10.0.0.52 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 52 |
+---------------+-------+
[root@db03 ~]# mysql -umha -pmha -h 10.0.0.53 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 53 |
+---------------+-------+
配置参数(db03)
在配置文件的[server default]下面添加以下参数:
master_ip_failover_script=/usr/local/bin/master_ip_failover
注意:其中/usr/local/bin/master_ip_failover,必须事先准备好
见本文最后
vim /usr/local/bin/master_ip_failover
改如下几行:
my $vip = '10.0.0.55/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";
其中第一行是vip地址
第二行是如eth0:1后面的:1,就是所谓的key
第三、四行是启动和停止的命令,注意所有节点的网卡必须是同名的,如ens33、eth0等方式都行
如果是ens33的话,就要改成
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
第四行同理
注:
如果有中文字符要转换为英文的
yun install -y dos2unix
dos2unix /usr/local/bin/master_ip_failover
还要更改权限,添加可执行权限
chmod +x /usr/local/bin/master_ip_failover
还需手工在主库上绑定vip(首次),注意一定要和配置文件中的ethN一致,我的是ens33:1(1是key指定的值)
ifconfig ens33:1 10.0.0.55/24
之后检查
仅第一次需要手工加
然后重启MHA(db03):
masterha_stop --conf=/etc/mha/app1.cnf
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover /var/log/mha/app1/manager.log 2>&1 &
附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.10.0.55/24'; # Virtual IP
my $key = "1";
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth0:$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" ) {
# $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 "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" ) {
# 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 "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";
`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=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n";
}
MHA工作原理
MHA自动故障切换的步骤
1.Manager会每隔3秒钟探测一次MASTER主库; (Hi, 主库你还活着吗?)
- ping_interval 控制间隔时间;
- ping_type 控制探测方式,SELECT(执行SELECT 1)和CONNECT(创建连接/断开连接)
2.如果Manager探测到MASTER主库故障、无法访问,Manager会执行下面操作:
- ①从其他node发起ssh连接,检查主库是否能够SSH上去;
- ②从其他node发起mysql连接,检查MASTER库是否能够登陆;
3.如果所有Node节点ssh连接、msyql主库连接均连接失败,则开始故障转移,简单地说
①找到数据最新的从库(通过对比relay-log,查看show slave status即可)
②将最新的从库上的新数据同步到其他从库
③提升一个从库为主库(一般情况提升数据最新的,二般情况提升我们指定的从库为主库)
④通过原来主库的binlog补全新的主库数据
⑤其他从库以新的主库为主做主从复制
详细步骤如下:
Phase 1
Configuration Check Phase…
检查数据库版本,检查是否启用GTID检查从库是否存活 检查配置文件的candidate
Phase 2
Dead Master Shutdown Phase.
该阶段会调用master_ip_failover脚本;去关闭所有Node的IO Thread
调用shutdown_script 强制关闭MASTER实例,防止应用程序来连接;
Phase 3
Master Recovery Phase…
Phase 3.1
Getting Latest Slaves Phase.
检查所有节点,从show slave status中对比获取最新的binlog/position
Phase 3.2
Saving Dead Master’s Binlog Phase…
如果老的Master可以SSH,上去获取BINLOG,从position到END位置,获取这段BINLOG(MASETER产生这段BINLOG,还未来得及发送给SLAVE)将这部分日志发送给Manager节点(manager_workdir位置);
如果故障Master无法SSH,则无法获取这段日志
Phase 3.3
Determining New Master Phase…
对比所有SLAVE,从最新SALVE中同步差异realy log给其他slave;最终确保所有SLAVE数据一致
Phase 3.3
New Master Diff Log Generation Phase…
确认新master 是否为最新slave,如果不是,则从最新slave获取差异日志;
将manager上获取的BINLOG日志发送给new master;
Phase 3.4
Master Log Apply Phase…
对比新master的Exec_Master_Log_Pos和Read_Master_Log_Pos,判断恢复的位置;
在本地回放 3.3 Phase的差异日志; 获取新master的binlog和position;
Phase 4
Slaves Recovery Phase…
Phase 4.1
Starting Parallel Slave Diff Log Generation Phase.
对每个SLAVE恢复:所有SLAVE和最新Slave做对比,如果position不一致,则生产差异日志
Phase 4.2
Starting Parallel Slave Log Apply Phase.
每个SLAVE 应用差异日志;
执行CHANGE MASTER 挂在到新Master
Phase 5
New master cleanup phase…
reset slave all;
MHA配置文件参数
-
配置文件中具体每个配置参数的解释:
-
hostname:目标实例的主机名或者IP地址,这个参数是强制的,只能配置在app配置文件的[server_xxx]段落标记下
-
ip:目标实例的ip地址,默认从hostname获取,MHA内部管理节点与数据节点之间的mysql和ssh通过这个IP连接,正常情况下你不需要配置这个参数,因为MHA会自动解析Hostname获得
-
port:目标实例的端口,默认是3306,MHA使用mysql server的IP和port连接
-
ssh_host:从0.53版本开始支持,默认情况下和hostname参数相同,当你使用了VLAN隔离的时候,比如为了安全,把ssh网段和访问数据库实例的网段分开使用两个不同的IP,那么就需要单独配置这个参数
-
ssh_ip:从0.53版本开始支持,默认情况下与ssh_host相同
-
ssh_port:从0.53版本开始支持,目标数据库的ssh端口,默认是22
-
ssh_connection_timeout:从0.54版本开始支持,默认是5秒,增加这个参数之前这个超时时间是写死在代码里的
-
ssh_options:从0.53版本开始支持,额外的ssh命令行选项
-
candidate_master:从不同的从库服务器中,提升一个可靠的机器为新主库,(比如:RAID 10比RAID0的从库更可靠),可以通过在配置文件中对应的从库服务器的配置段下添加candidate_master=1来提升这个从库被提升为新主库的优先级(这个从库要开始binlog,以及没有显著的复制延迟,如果不满足这两个条件,也并不会在主库挂掉的时候成为新主库,所以,这个参数只是提升了优先级,并不是说指定了这个参数就一定会成为新主库)
-
no_master:通过在目标服务器的配置段落设置no_master=1,它永远也不会变为新主库,用于配置在不想用于接管主库故障的从库上,如:只是一个binlog server,或者硬件配置比较差的从库上,或者这个从库只是一个远程灾备的从库,但是,要注意,不能把所有的从库都配置这个参数,这样MHA检测到没有可用备主的时候,会中断故障转移操作
-
ignore_fail:默认情况下,MHA在做故障转移的时候,会去检测所有的server,如果发现有任何的从库有问题(比如不能通过SSH检测主机或者mysql的存活,或者说有SQL线程复制错误等)就不会进行故障转移操作,但是,有时候可能需要在特定从库有故障的情况下,仍然继续进行故障转移,就可以使用这个参数指定它。默认是0,需要设置时在对应服务器的配置段下添加ignore_fail=1
-
skip_init_ssh_check:监控程序启动的时候,跳过SSH连接检测
-
skip_reset_slave:0.56开始支持,master故障转移之后,跳过执行reset slave all语句
-
user:目标mysql实例的管理帐号,尽量是root用户,因为运行所有的管理命令(如:stop slave,change master,reset slave)需要使用,默认是root
-
password:user参数指定的用户的密码,默认为空
-
repl_user:在所有slave上执行change master的复制用户名,这个用户最好是在主库上拥有replication slave权限
-
repl_password:repl_user参数指定的用户的密码,默认情况下,是当前复制帐号的密码,如果你运行了online master switch脚本且使用了–orig_master_is_new_slave做在线切换,当前主库作为了从库加入新主库,此时,如果你没有设置repl_password来指定复制帐号的密码,当前主库作为从库加入新主库的时候会在change master的时候失败,因为默认情况下这个密码是空的,MHA做切换的时候,其他所有作为从库加入新主库时,都需要使用这个密码
-
disable_log_bin:如果设置这个参数,当应用差异日志到从库时,slave不生成binlog写入,内部通过mysqlbinlog命令的–disable-log-bin选项实现
-
master_pid_file:设置master的pid,在运行多实例的环境下,你可能需要用到这个参数来指定master的pid,参考shutdown_script参数详解
-
ssh_user:访问MHA manger和MHA mysql节点的OS系统帐号,需要使用它来远程执行各种各样的管理mysql节点的命令(从manager到mysql),从latest slave拷贝差异日志到其他从库上(从mysql到mysql),该用户必须要能够没有任何交互地连接到服务器,通常使用ssh key认证,默认情况下,这个用户是manager所在的OS系统用户。
-
remote_workdir:每一个MHA node(指的是mysql server节点)生成日志文件的工作路径,这个路径是绝对路径,如果该路径目录不存在,则会自动创建,如果没有权限访问这个路径,那么MHA将终止后续过程,另外,你需要关心一下这个路径下的文件系统是否有足够的磁盘空间,默认值是/var/tmp
-
master_binlog_dir:在master上生成binlog的绝对路径,这个参数用在master挂了,但是ssh还可达的时候,从主库的这个路径下读取和复制必须的binlog events,这个参数是必须的,因为master的mysqld挂掉之后,没有办法自动识别master的binlog存放目录。默认情况下,master_binlog_dir的值是/var/lib/mysql,/var/log/mysql,/var/lib/mysql目录是大多数mysql分支默认的binlog输出目录,而 /var/log/mysql是ubuntu包的默认binlog输出目录,这个参数可以设置多个值,用逗号隔开
-
log_level:manager记录日志的等级,默认以及大多数场景下都是info级别,可以设置的值为debug/info/warning/error
-
manager_workdir:mha manager生成的相关状态文件的绝对路径,如果没有设置,则默认使用/var/tmp
-
client_bindir: 如果mysql命令工具是安装在非标准路径下,那么使用这个参数指定绝对路径
-
client_libdir:如果mysql的库文件是安装在非标准路径下,那么使用这个参数指定据对路径
-
manager_log:mha manager生成的日志据对路径,如果没有设置,mha manager将打印在标准输出,标准错误输出上,如:当mha manager执行故障转移的时候,这些信息就会打印
-
check_repl_delay:默认情况下,如果从库落后主库100M的relay logs,MHA不会选择这个从库作为新主库,因为它会增加恢复的时间,设置这个参数为0,MHA在选择新主库的时候,则忽略复制延迟,这个选项用在你使用candidate_master=1 明确指定需要哪个从库作为新主库的时候使用。
-
check_repl_filter:默认情况下,如果master和slave相互之间有任何不同的binlog复制过滤规则,MHA将打印错误日志并拒绝启动监控程序或者拒绝故障转移操作,这是为了避免意外出现类似Table not exists这样的错误,如果你100%确定不同的复制过滤规则不会出现恢复问题,那么就设置check_repl_filter = 0,此时MHA在应用差异日志的时候就不会去检测复制过滤规则,但是你可能会碰到Table not exists这样的错误,使用这个参数要非常小心
-
latest_priority:默认情况下,latest slave(收到最新的binlog的slave),优先作为新主库,如果你想控制这个优先级顺序,可以通过 latest_priority=0,此时,就会按照配置文件中配置的顺序来选择新主库(如 host2->host3->host4)。
-
multi_tier_slave:从0.52版本开始,支持多个主库的复制架构,默认情况下,在配置文件中不支持三个或更多层级的复制架构,例如:host2从host1复制,host3从host2复制,默认情况下,是不允许host1,2,3同时可写的。因为这个是一个三层复制,MHA manager会报错并停止,设置这个参数之后,MHA manager不会中断三层复制架构的监控,只是忽略了第三层,即host3,如果host1挂了,host2将接管host1,被选择为新主库,host3继续从host3复制。
-
ping_interval:这个参数表示mha manager多久ping(执行select ping sql语句)一次master,连续三个丢失ping连接,mha master就判定mater死了,因此,通过4次ping间隔的最大时间的机制来发现故障,默认是3,表示间隔是3秒
-
ping_type:从0.53版本开始支持,默认情况下,mha master基于一个到master的已经存在的连接执行select 1(ping_type=select)语句来检查master的可用性,但是在有些场景下,最好是每次通过新建/断开连接的方式来检测,因为这能够更严格以及更快速地发现TCP连接级别的故障,把ping_type设置为connect就可以实现。从0.56开始新增了ping_type=INSERT类型。
-
secondary_check_script:通常,推荐通过两个或者更多的网络路径来检测master的可用性,默认情况下,MHA只是通过单个网络路径来检测,即从mha master到master的路线,但是不推荐这么做,mha可以通过secondary_check_script 参数来调用一个外部的脚本来实现两个或更多个网络路径来检测master的可用性,配置示例如下:
secondary_check_script = masterha_secondary_check -s remote_host1 -s remote_host2 masterha_secondary_check 脚本包含在mha manager的安装包里,这个脚本适合大多数的场景,但是你可以调用任何你自定义的脚本。 在上述的示例中,mha manager检测master的存活的网络路径是:mha manager–>remote_host1–>master_host和mha manager–>remote_host2–>master_host,如果两条线路中,mha master到远程主机的连接是通的,但是远程主机到master不通,这个脚本返回状态0,那么mha就判定master死了。 将开始执行故障转移。如果mha manager到远程主机都不通,那么这个脚本返回状态2,mha manager就猜测网络可能发生了问题了,拒绝执行故障转移操作。如果两条线路从头到位都走通了,那么这个脚本返回状态3,此时mha master知道主库是或者的,就不会进行故障转移操作。 通常来说,remote_host1和remote_host2需要处于本地的两个不同的网段 mha调用secondary_check_script 脚本自动地传递如下参数(不需要你在配置文件中的secondary_check_script 参数中指定这些参数),如果你需要更多的功能,你可以自定义这个脚本: –user:远程主机ssh用户名,如果指定了这个,那么ssh_user参数就会被忽略 –master_host:指定master的主机名(实例) –master_ip:指定master的IP(实例) –master_port:指定master的端口号(实例) PS:运行这个脚本需要依赖perl的 IO::Socket::INET包,这个包包含在perl的5.6.0里,masterha_secondary_check 脚本仍然通过免密钥的ssh来连接远程服务器,这个脚本尝试从远程服务器建立到master的TCP连接,这个意思是my.cnf中的max_connections 参数对这个么有 影响,如果这个TCP连接成功了,在mysql的Aborted_connects 变量中会增加1
-
master_ip_failover_script:通常在MHA环境下,通常需要分配一个VIP供master用于对外提供读写服务,如果master挂了,HA软件指引备用服务器接管VIP,另外一个通用的方法,是在数据库中创建一个全局的应用程序名称与读写IP地址之间的全局类目映射( {app1_master1, 192.168.0.1}, {app_master2, 192.168.0.2}, …)来代替VIP地址的使用,在这种情况下,如果你的master挂了,你需要更新这个数据库中的全局类目映射。第二种方法这里个人觉得跟智能DNS解析类似。
两种方法各有优缺点,MHA不强制使用哪一种方法,但是允许用户使用任何IP地址做故障转移的方案,master_ip_failover_script 参数可以用于实现这个目的,换句话说,你需要自己编写一个脚本来透明地把应用程序连接到新主库上。需要在配置文件中定义这个参数,示例如下: master_ip_failover_script= /usr/local/sample/bin/master_ip_failover mha manager安装包中(tar包和githup分支上才有,rpm包没有)的samples/scripts/master_ip_failover路径下有一个简单的脚本 mha manager会调用master_ip_failover_script 这个参数指定的脚本三次,第一次是在进入主库监控之前(为了检测脚本的有效性),第二次是将要调用shutdown_script参数的脚本之前,第三次是新主库应用完成了差异relay log之后,mha manager调用这个脚本会用到如下参数(注意:你不需要在配置文件中这个参数上单独设置这些) 检测阶段参数: –command=status –ssh_user=(current master’s ssh username) –orig_master_host=(current master’s hostname) –orig_master_ip=(current master’s ip address) –orig_master_port=(current master’s port number) 关闭当前master的阶段参数(注意,到调用shutdown_script的时候,主库已经被判定为死了): –command=stop or stopssh –ssh_user=(dead master’s ssh username, if reachable via ssh) –orig_master_host=(current(dead) master’s hostname) –orig_master_ip=(current(dead) master’s ip address) –orig_master_port=(current(dead) master’s port number) 新的master激活阶段参数: –command=start –ssh_user=(new master’s ssh username) –orig_master_host=(dead master’s hostname) –orig_master_ip=(dead master’s ip address) –orig_master_port=(dead master’s port number) –new_master_host=(new master’s hostname) –new_master_ip=(new master’s ip address) –new_master_port(new master’s port number) –new_master_user=(new master’s user) –new_master_password(new master’s password) 如果你在master上使用的是共享VIP,那么在master的shutdown阶段就不需要做任何事情,只要在shutdown_script脚本关闭机器的电源之后,在新的master的激活阶段,在新的master上分配这个VIP即可,如果你使用的是一个全局类目映射的方案,你可能需要在shutdown死掉的master阶段之后,删除或者更新对应的dead master的记录。在新的master的激活阶段,你可以新增或者更新对应的新的master的记录,然后,你可以做一些事情(如:在新主库上执行set global read_only=0;以及创建数据库用户的写权限),以便应用程序就可以在新的主库上写入数据了 mha manager会检测脚本执行退出的代号,如果是0或者10,mha manager则继续操作,如果返回的是0和10以外的代号,mha manager停止并中断故障转移,默认情况下,这个参数为空,所以,默认情况下mha不会调用这个脚本做任何事情。
-
master_ip_online_change_script:这是一个与master_ip_failover_script 参数很接近的参数,但是这个参数不使用故障转移命令,而是master的在线change命令(masterha_master_switch –master_state=alive),使用如下参数(注意:你不需要在配置文件中这个参数上单独设置这些):
冻结当前主库写操作阶段的参数: –command=stop or stopssh –orig_master_host=(current master’s hostname) –orig_master_ip=(current master’s ip address) –orig_master_port=(current master’s port number) –orig_master_user=(current master’s user) –orig_master_password=(current master’s password) –orig_master_ssh_user=(from 0.56, current master’s ssh user) –orig_master_is_new_slave=(from 0.56, notifying whether the orig master will be new slave or not) 允许新的主库写阶段的参数: –command=start –orig_master_host=(orig master’s hostname) –orig_master_ip=(orig master’s ip address) –orig_master_port=(orig master’s port number) –new_master_host=(new master’s hostname) –new_master_ip=(new master’s ip address) –new_master_port(new master’s port number) –new_master_user=(new master’s user) –new_master_password=(new master’s password) –new_master_ssh_user=(from 0.56, new master’s ssh user) 在冻结当前主库写的阶段,mha manager在当前主库上执行FLUSH TABLES WITH READ LOCK,你可以写任何的逻辑来优雅地实现主库的切换(参考http://www.slideshare.net/matsunobu/automated-master-failover/44),在新的master允许写的阶段,你可以做和master_ip_failover_script脚本的第三阶段几乎一样的事情,例如:在新的主库上创建写权限用户和执行set global read_only=0语句,或者更新全局类目映射记录,如果这个脚本执行返回状态吗是0或者10以外的值,mha manager将终止并停止master在线切换操作。默认这个参数为空,mha不会调用这个参数做任何事情,在mha manager的tar包和githup分支下的samples/scripts/master_ip_online_change路径下有一个简单的脚本。
-
shutdown_script:你可能想要强制关闭master节点来避免master节点重新启动服务,这对于避免脑裂来说是很重要的,示例:
shutdown_script= /usr/local/sample/bin/power_manager 在mha manager的tar包和github的分支的samples/scripts/power_manager路径下有一个简单的脚本,在调用这个脚本之前,mha manager内部会通过ssh去检测master是否可达,如果ssh可达(主机OS活着但是mysqld挂了),mha manager使用如下参数: –command=stopssh –ssh_user=(ssh username so that you can connect to the master) –host=(master’s hostname) –ip=(master’s ip address) –port=(master’s port number) –pid_file=(master’s pid file) 如果master通过ssh不可达,那么mha manager就会使用如下参数: –command=stop –host=(master’s hostname) –ip=(master’s ip address) 这个脚本工作流程如下: 如果通过–command=stopssh参数,这个脚本通过ssh过去master上kill -9杀掉mysqld和mysqld_safe进程,如果同时也通过–pid_file参数,这个脚本通过ssh过去主库上只kill -9杀掉指定的进程号,不会杀掉所有的进程,这个对在master上运行多实例的时候有帮助,如果通过ssh停止成功,这个脚本退出状态是10,如果退出状态是10,mha manager随后就通过ssh连接到master保存必要的binlog,如果这个脚本通过ssh连接master失败,或者mha manager是使用的参数 –command=stop,这个脚本就会尝试关闭机器的电源,关闭机器的命令依赖硬件(For HP(iLO), 通常是ipmitool or SSL,For Dell(DRAC), 通常是dracadm),如果关闭电源成功,这个脚本的退出状态是0,否则退出的状态是1,如果这个脚本的退出状态是0,则mha manager开始执行故障转移过程,如果这个状态是0和10以外的其他状态,则mha终止故障转移,默认这个参数为空,所以mha不会调用这个参数做任何事情。 另外,mha manager开始监控的时候会调用shutdown_script 参数,在这次调用会使用以下参数,在这里可以检测脚本的设置,控制电源需要高度依赖硬件,所以建议要检测电源的状态,如果发现什么问题,你可以在启动监控程序之前去解决。 –command=status –host=(master’s hostname) –ip=(master’s ip address)
-
report_script:在故障转移完成或者说因为错误而终止的时候,你可能希望发送一个报告出来,这就是使用report_script 参数的目的,mha manager通过如下参数使用这个脚本:
–orig_master_host=(dead master’s hostname) –new_master_host=(new master’s hostname) –new_slave_hosts=(new slaves’ hostnames, delimited by commas) –subject=(mail subject) –body=(body) 默认情况下,这个参数是空的,mha manager不会调用这个参数做任何事情,在mha manager的tar包和github分支的samples/scripts/send_report路径下有一个简单的脚本。
-
init_conf_load_script:这个脚本在你不想在配置文件中设置纯文本的信息的时候使用(比如:password和repl_password),从这个脚本返回name=value的键值对,它可以作为全局配置文件参数,示例脚本内容如下:
配置文件中具体每个配置参数的解释:
-
hostname:目标实例的主机名或者IP地址,这个参数是强制的,只能配置在app配置文件的[server_xxx]段落标记下
-
ip:目标实例的ip地址,默认从hostname获取,MHA内部管理节点与数据节点之间的mysql和ssh通过这个IP连接,正常情况下你不需要配置这个参数,因为MHA会自动解析Hostname获得
-
port:目标实例的端口,默认是3306,MHA使用mysql server的IP和port连接
-
ssh_host:从0.53版本开始支持,默认情况下和hostname参数相同,当你使用了VLAN隔离的时候,比如为了安全,把ssh网段和访问数据库实例的网段分开使用两个不同的IP,那么就需要单独配置这个参数
-
ssh_ip:从0.53版本开始支持,默认情况下与ssh_host相同
-
ssh_port:从0.53版本开始支持,目标数据库的ssh端口,默认是22
-
ssh_connection_timeout:从0.54版本开始支持,默认是5秒,增加这个参数之前这个超时时间是写死在代码里的
-
ssh_options:从0.53版本开始支持,额外的ssh命令行选项
-
candidate_master:从不同的从库服务器中,提升一个可靠的机器为新主库,(比如:RAID 10比RAID0的从库更可靠),可以通过在配置文件中对应的从库服务器的配置段下添加candidate_master=1来提升这个从库被提升为新主库的优先级(这个从库要开始binlog,以及没有显著的复制延迟,如果不满足这两个条件,也并不会在主库挂掉的时候成为新主库,所以,这个参数只是提升了优先级,并不是说指定了这个参数就一定会成为新主库)
-
no_master:通过在目标服务器的配置段落设置no_master=1,它永远也不会变为新主库,用于配置在不想用于接管主库故障的从库上,如:只是一个binlog server,或者硬件配置比较差的从库上,或者这个从库只是一个远程灾备的从库,但是,要注意,不能把所有的从库都配置这个参数,这样MHA检测到没有可用备主的时候,会中断故障转移操作
-
ignore_fail:默认情况下,MHA在做故障转移的时候,会去检测所有的server,如果发现有任何的从库有问题(比如不能通过SSH检测主机或者mysql的存活,或者说有SQL线程复制错误等)就不会进行故障转移操作,但是,有时候可能需要在特定从库有故障的情况下,仍然继续进行故障转移,就可以使用这个参数指定它。默认是0,需要设置时在对应服务器的配置段下添加ignore_fail=1
-
skip_init_ssh_check:监控程序启动的时候,跳过SSH连接检测
-
skip_reset_slave:0.56开始支持,master故障转移之后,跳过执行reset slave all语句
-
user:目标mysql实例的管理帐号,尽量是root用户,因为运行所有的管理命令(如:stop slave,change master,reset slave)需要使用,默认是root
-
password:user参数指定的用户的密码,默认为空
-
repl_user:在所有slave上执行change master的复制用户名,这个用户最好是在主库上拥有replication slave权限
-
repl_password:repl_user参数指定的用户的密码,默认情况下,是当前复制帐号的密码,如果你运行了online master switch脚本且使用了–orig_master_is_new_slave做在线切换,当前主库作为了从库加入新主库,此时,如果你没有设置repl_password来指定复制帐号的密码,当前主库作为从库加入新主库的时候会在change master的时候失败,因为默认情况下这个密码是空的,MHA做切换的时候,其他所有作为从库加入新主库时,都需要使用这个密码
-
disable_log_bin:如果设置这个参数,当应用差异日志到从库时,slave不生成binlog写入,内部通过mysqlbinlog命令的–disable-log-bin选项实现
-
master_pid_file:设置master的pid,在运行多实例的环境下,你可能需要用到这个参数来指定master的pid,参考shutdown_script参数详解
-
ssh_user:访问MHA manger和MHA mysql节点的OS系统帐号,需要使用它来远程执行各种各样的管理mysql节点的命令(从manager到mysql),从latest slave拷贝差异日志到其他从库上(从mysql到mysql),该用户必须要能够没有任何交互地连接到服务器,通常使用ssh key认证,默认情况下,这个用户是manager所在的OS系统用户。
-
remote_workdir:每一个MHA node(指的是mysql server节点)生成日志文件的工作路径,这个路径是绝对路径,如果该路径目录不存在,则会自动创建,如果没有权限访问这个路径,那么MHA将终止后续过程,另外,你需要关心一下这个路径下的文件系统是否有足够的磁盘空间,默认值是/var/tmp
-
master_binlog_dir:在master上生成binlog的绝对路径,这个参数用在master挂了,但是ssh还可达的时候,从主库的这个路径下读取和复制必须的binlog events,这个参数是必须的,因为master的mysqld挂掉之后,没有办法自动识别master的binlog存放目录。默认情况下,master_binlog_dir的值是/var/lib/mysql,/var/log/mysql,/var/lib/mysql目录是大多数mysql分支默认的binlog输出目录,而 /var/log/mysql是ubuntu包的默认binlog输出目录,这个参数可以设置多个值,用逗号隔开
-
log_level:manager记录日志的等级,默认以及大多数场景下都是info级别,可以设置的值为debug/info/warning/error
-
manager_workdir:mha manager生成的相关状态文件的绝对路径,如果没有设置,则默认使用/var/tmp
-
client_bindir: 如果mysql命令工具是安装在非标准路径下,那么使用这个参数指定绝对路径
-
client_libdir:如果mysql的库文件是安装在非标准路径下,那么使用这个参数指定据对路径
-
manager_log:mha manager生成的日志据对路径,如果没有设置,mha manager将打印在标准输出,标准错误输出上,如:当mha manager执行故障转移的时候,这些信息就会打印
-
check_repl_delay:默认情况下,如果从库落后主库100M的relay logs,MHA不会选择这个从库作为新主库,因为它会增加恢复的时间,设置这个参数为0,MHA在选择新主库的时候,则忽略复制延迟,这个选项用在你使用candidate_master=1 明确指定需要哪个从库作为新主库的时候使用。
-
check_repl_filter:默认情况下,如果master和slave相互之间有任何不同的binlog复制过滤规则,MHA将打印错误日志并拒绝启动监控程序或者拒绝故障转移操作,这是为了避免意外出现类似Table not exists这样的错误,如果你100%确定不同的复制过滤规则不会出现恢复问题,那么就设置check_repl_filter = 0,此时MHA在应用差异日志的时候就不会去检测复制过滤规则,但是你可能会碰到Table not exists这样的错误,使用这个参数要非常小心
-
latest_priority:默认情况下,latest slave(收到最新的binlog的slave),优先作为新主库,如果你想控制这个优先级顺序,可以通过 latest_priority=0,此时,就会按照配置文件中配置的顺序来选择新主库(如 host2->host3->host4)。
-
multi_tier_slave:从0.52版本开始,支持多个主库的复制架构,默认情况下,在配置文件中不支持三个或更多层级的复制架构,例如:host2从host1复制,host3从host2复制,默认情况下,是不允许host1,2,3同时可写的。因为这个是一个三层复制,MHA manager会报错并停止,设置这个参数之后,MHA manager不会中断三层复制架构的监控,只是忽略了第三层,即host3,如果host1挂了,host2将接管host1,被选择为新主库,host3继续从host3复制。
-
ping_interval:这个参数表示mha manager多久ping(执行select ping sql语句)一次master,连续三个丢失ping连接,mha master就判定mater死了,因此,通过4次ping间隔的最大时间的机制来发现故障,默认是3,表示间隔是3秒
-
ping_type:从0.53版本开始支持,默认情况下,mha master基于一个到master的已经存在的连接执行select 1(ping_type=select)语句来检查master的可用性,但是在有些场景下,最好是每次通过新建/断开连接的方式来检测,因为这能够更严格以及更快速地发现TCP连接级别的故障,把ping_type设置为connect就可以实现。从0.56开始新增了ping_type=INSERT类型。
-
secondary_check_script:通常,推荐通过两个或者更多的网络路径来检测master的可用性,默认情况下,MHA只是通过单个网络路径来检测,即从mha master到master的路线,但是不推荐这么做,mha可以通过secondary_check_script 参数来调用一个外部的脚本来实现两个或更多个网络路径来检测master的可用性,配置示例如下:
secondary_check_script = masterha_secondary_check -s remote_host1 -s remote_host2 masterha_secondary_check 脚本包含在mha manager的安装包里,这个脚本适合大多数的场景,但是你可以调用任何你自定义的脚本。 在上述的示例中,mha manager检测master的存活的网络路径是:mha manager–>remote_host1–>master_host和mha manager–>remote_host2–>master_host,如果两条线路中,mha master到远程主机的连接是通的,但是远程主机到master不通,这个脚本返回状态0,那么mha就判定master死了。 将开始执行故障转移。如果mha manager到远程主机都不通,那么这个脚本返回状态2,mha manager就猜测网络可能发生了问题了,拒绝执行故障转移操作。如果两条线路从头到位都走通了,那么这个脚本返回状态3,此时mha master知道主库是或者的,就不会进行故障转移操作。 通常来说,remote_host1和remote_host2需要处于本地的两个不同的网段 mha调用secondary_check_script 脚本自动地传递如下参数(不需要你在配置文件中的secondary_check_script 参数中指定这些参数),如果你需要更多的功能,你可以自定义这个脚本: –user:远程主机ssh用户名,如果指定了这个,那么ssh_user参数就会被忽略 –master_host:指定master的主机名(实例) –master_ip:指定master的IP(实例) –master_port:指定master的端口号(实例) PS:运行这个脚本需要依赖perl的 IO::Socket::INET包,这个包包含在perl的5.6.0里,masterha_secondary_check 脚本仍然通过免密钥的ssh来连接远程服务器,这个脚本尝试从远程服务器建立到master的TCP连接,这个意思是my.cnf中的max_connections 参数对这个么有 影响,如果这个TCP连接成功了,在mysql的Aborted_connects 变量中会增加1 -
master_ip_failover_script:通常在MHA环境下,通常需要分配一个VIP供master用于对外提供读写服务,如果master挂了,HA软件指引备用服务器接管VIP,另外一个通用的方法,是在数据库中创建一个全局的应用程序名称与读写IP地址之间的全局类目映射( {app1_master1, 192.168.0.1}, {app_master2, 192.168.0.2}, …)来代替VIP地址的使用,在这种情况下,如果你的master挂了,你需要更新这个数据库中的全局类目映射。第二种方法这里个人觉得跟智能DNS解析类似。
两种方法各有优缺点,MHA不强制使用哪一种方法,但是允许用户使用任何IP地址做故障转移的方案,master_ip_failover_script 参数可以用于实现这个目的,换句话说,你需要自己编写一个脚本来透明地把应用程序连接到新主库上。需要在配置文件中定义这个参数,示例如下: master_ip_failover_script= /usr/local/sample/bin/master_ip_failover mha manager安装包中(tar包和githup分支上才有,rpm包没有)的samples/scripts/master_ip_failover路径下有一个简单的脚本 mha manager会调用master_ip_failover_script 这个参数指定的脚本三次,第一次是在进入主库监控之前(为了检测脚本的有效性),第二次是将要调用shutdown_script参数的脚本之前,第三次是新主库应用完成了差异relay log之后,mha manager调用这个脚本会用到如下参数(注意:你不需要在配置文件中这个参数上单独设置这些) 检测阶段参数: –command=status –ssh_user=(current master’s ssh username) –orig_master_host=(current master’s hostname) –orig_master_ip=(current master’s ip address) –orig_master_port=(current master’s port number) 关闭当前master的阶段参数(注意,到调用shutdown_script的时候,主库已经被判定为死了): –command=stop or stopssh –ssh_user=(dead master’s ssh username, if reachable via ssh) –orig_master_host=(current(dead) master’s hostname) –orig_master_ip=(current(dead) master’s ip address) –orig_master_port=(current(dead) master’s port number) 新的master激活阶段参数: –command=start –ssh_user=(new master’s ssh username) –orig_master_host=(dead master’s hostname) –orig_master_ip=(dead master’s ip address) –orig_master_port=(dead master’s port number) –new_master_host=(new master’s hostname) –new_master_ip=(new master’s ip address) –new_master_port(new master’s port number) –new_master_user=(new master’s user) –new_master_password(new master’s password) 如果你在master上使用的是共享VIP,那么在master的shutdown阶段就不需要做任何事情,只要在shutdown_script脚本关闭机器的电源之后,在新的master的激活阶段,在新的master上分配这个VIP即可,如果你使用的是一个全局类目映射的方案,你可能需要在shutdown死掉的master阶段之后,删除或者更新对应的dead master的记录。在新的master的激活阶段,你可以新增或者更新对应的新的master的记录,然后,你可以做一些事情(如:在新主库上执行set global read_only=0;以及创建数据库用户的写权限),以便应用程序就可以在新的主库上写入数据了 mha manager会检测脚本执行退出的代号,如果是0或者10,mha manager则继续操作,如果返回的是0和10以外的代号,mha manager停止并中断故障转移,默认情况下,这个参数为空,所以,默认情况下mha不会调用这个脚本做任何事情。 -
master_ip_online_change_script:这是一个与master_ip_failover_script 参数很接近的参数,但是这个参数不使用故障转移命令,而是master的在线change命令(masterha_master_switch –master_state=alive),使用如下参数(注意:你不需要在配置文件中这个参数上单独设置这些):
冻结当前主库写操作阶段的参数: –command=stop or stopssh –orig_master_host=(current master’s hostname) –orig_master_ip=(current master’s ip address) –orig_master_port=(current master’s port number) –orig_master_user=(current master’s user) –orig_master_password=(current master’s password) –orig_master_ssh_user=(from 0.56, current master’s ssh user) –orig_master_is_new_slave=(from 0.56, notifying whether the orig master will be new slave or not) 允许新的主库写阶段的参数: –command=start –orig_master_host=(orig master’s hostname) –orig_master_ip=(orig master’s ip address) –orig_master_port=(orig master’s port number) –new_master_host=(new master’s hostname) –new_master_ip=(new master’s ip address) –new_master_port(new master’s port number) –new_master_user=(new master’s user) –new_master_password=(new master’s password) –new_master_ssh_user=(from 0.56, new master’s ssh user) 在冻结当前主库写的阶段,mha manager在当前主库上执行FLUSH TABLES WITH READ LOCK,你可以写任何的逻辑来优雅地实现主库的切换(参考http://www.slideshare.net/matsunobu/automated-master-failover/44),在新的master允许写的阶段,你可以做和master_ip_failover_script脚本的第三阶段几乎一样的事情,例如:在新的主库上创建写权限用户和执行set global read_only=0语句,或者更新全局类目映射记录,如果这个脚本执行返回状态吗是0或者10以外的值,mha manager将终止并停止master在线切换操作。默认这个参数为空,mha不会调用这个参数做任何事情,在mha manager的tar包和githup分支下的samples/scripts/master_ip_online_change路径下有一个简单的脚本。 -
shutdown_script:你可能想要强制关闭master节点来避免master节点重新启动服务,这对于避免脑裂来说是很重要的,示例:
shutdown_script= /usr/local/sample/bin/power_manager 在mha manager的tar包和github的分支的samples/scripts/power_manager路径下有一个简单的脚本,在调用这个脚本之前,mha manager内部会通过ssh去检测master是否可达,如果ssh可达(主机OS活着但是mysqld挂了),mha manager使用如下参数: –command=stopssh –ssh_user=(ssh username so that you can connect to the master) –host=(master’s hostname) –ip=(master’s ip address) –port=(master’s port number) –pid_file=(master’s pid file) 如果master通过ssh不可达,那么mha manager就会使用如下参数: –command=stop –host=(master’s hostname) –ip=(master’s ip address) 这个脚本工作流程如下: 如果通过–command=stopssh参数,这个脚本通过ssh过去master上kill -9杀掉mysqld和mysqld_safe进程,如果同时也通过–pid_file参数,这个脚本通过ssh过去主库上只kill -9杀掉指定的进程号,不会杀掉所有的进程,这个对在master上运行多实例的时候有帮助,如果通过ssh停止成功,这个脚本退出状态是10,如果退出状态是10,mha manager随后就通过ssh连接到master保存必要的binlog,如果这个脚本通过ssh连接master失败,或者mha manager是使用的参数 –command=stop,这个脚本就会尝试关闭机器的电源,关闭机器的命令依赖硬件(For HP(iLO), 通常是ipmitool or SSL,For Dell(DRAC), 通常是dracadm),如果关闭电源成功,这个脚本的退出状态是0,否则退出的状态是1,如果这个脚本的退出状态是0,则mha manager开始执行故障转移过程,如果这个状态是0和10以外的其他状态,则mha终止故障转移,默认这个参数为空,所以mha不会调用这个参数做任何事情。 另外,mha manager开始监控的时候会调用shutdown_script 参数,在这次调用会使用以下参数,在这里可以检测脚本的设置,控制电源需要高度依赖硬件,所以建议要检测电源的状态,如果发现什么问题,你可以在启动监控程序之前去解决。 –command=status –host=(master’s hostname) –ip=(master’s ip address) -
report_script:在故障转移完成或者说因为错误而终止的时候,你可能希望发送一个报告出来,这就是使用report_script 参数的目的,mha manager通过如下参数使用这个脚本:
–orig_master_host=(dead master’s hostname) –new_master_host=(new master’s hostname) –new_slave_hosts=(new slaves’ hostnames, delimited by commas) –subject=(mail subject) –body=(body) 默认情况下,这个参数是空的,mha manager不会调用这个参数做任何事情,在mha manager的tar包和github分支的samples/scripts/send_report路径下有一个简单的脚本。 -
init_conf_load_script:这个脚本在你不想在配置文件中设置纯文本的信息的时候使用(比如:password和repl_password),从这个脚本返回name=value的键值对,它可以作为全局配置文件参数,示例脚本内容如下:
#!/usr/bin/perl`
print "password=$ROOT_PASS\n";`
print "repl_password=$REPL_PASS\n";`
这个参数默认为空,所以mha manager不会调用这个参数做任何事情
参考:
https://zhuanlan.zhihu.com/p/396007930