14 数据库高可用
MHA工作原理
MHA的组成
MHA由node和manager组成；
- MHA Node(数据节点)：
相当于监控客户端,所有数据库机器都需要部署node
-
MHA Manager(管理节点)
Manager相当于服务端，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master（如果原主库恢复，只能当从库）。
通常单独部署在一台独立机器上管理多个 master/slave 集群(组)，每个 master/slave 集群称作一个 application，用来管理统筹整个集群。
Manager应该尽量避免部署在主库上，否则主机一挂则全挂，不仅主库完蛋了，负责自动迁移的Manager也完蛋了，也没人负责自动故障迁移了，导致架构不可用了。
可以考虑部署在某一个slave上，此时这台主机挂掉了，只是挂了一个slave，以及Manager，如果此时你不是倒了霉，（主库也挂了），那还不至于架构不可用。但有一点需要注意的是：如果Manager部署在slave上，那么该slave就无法被升级为主库；
由上图我们可以看出，每个复制组内部和 Manager 之间都需要ssh实现无密码互连，只有这样，在 Master 出故障时， Manager 才能顺利的连接进去，实现主从切换功能。
MHA自动故障切换的步骤
（1）， Manager会每隔3秒钟探测一次MASTER主库； （Hi, 主库你还活着吗？）
ping_interval 控制间隔时间；
ping_type 控制探测方式，SELECT（执行SELECT 1）和CONNECT（创建连接/断开连接）
（2）， 如果Manager探测到MASTER主库故障、无法访问，Manager会执行下面操作：
1、从其他node发起ssh连接，检查主库是否能够SSH上去；
2、从其他node发起mysql连接，检查MASTER库是否能够登陆；
（3）， 如果所有Node节点ssh连接、msyql主库连接均连接失败，则开始故障转移，
简单地说
1.找到数据最新的从库（通过对比relay-log，查看show slave status即可）
2.将最新的从库上的新数据同步到其他从库
3.提升一个从库为主库（一般情况提升数据最新的，二般情况提升我们指定的从库为主库）
4.通过原来主库的binlog补全新的主库数据
5.其他从库以新的主库为主做主从复制
详细步骤如下：
| 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; |
1、自动的故障检测与转移，通常在10-30秒以内;
2、MHA还提供在线主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中(通过将从库提升为主库),大概0.5-2秒内即可完成。
3、很好地解决了主库崩溃数据的一致性问题
4、不需要对当前的mysql环境做重大修改
5、不需要在现有的复制框架中添加额外的服务器，仅需要一个manager节点，而一个Manager能管理多套复制，所以能大大地节约服务器的数量;
6、性能优秀，可以工作在半同步和异步复制框架，支持gtid，当监控mysql状态时，仅需要每隔N秒向master发送ping包(默认3秒)，所以对性能无影响。你可以理解为MHA的性能和简单的主从复制框架性能一样。
7、只要replication支持的存储引擎都支持MHA，不会局限于innodb
8、对于一般的keepalived高可用，当vip在一台机器上的时候，另一台机器是闲置的，而MHA中并无闲置主机。
GTID主从复制
介绍
从MySQL 5.6.2 开始新增了一种基于 GTID 的复制方式，用以替代以前传统的复制方式，到MySQL5.6.10后逐渐完善。通过 GTID 保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的主备一致性，故障恢复以及容错能力，那么它如何做到的呢？
要想在分布式集群环境中不丢失事务，就必须为每个事务定制一个全局唯一的ID号，并且该ID是趋势递增的，以此我们便可以方便地顺序读取、不丢事务，其实GTID就是一种很好的分布式ID实践方案，它满足分布ID的两个基本要求
1）全局唯一性
2）趋势递增
GTID (Global Transaction ID全局事务ID)是如何做到全局唯一且趋势递增的呢，它是由UUID+TID两部分组成
UUID是数据库实例的标识符
TID表示事务提交的数量，会随着事务的提交递增
#具体形式：5426a3c1-ade1-11e9-90b3-000c29bb4490:23
因此他与主库上提交的每个事务相关联,GTID不仅对其发起的服务器是唯一的，而且在给定复制设置中的所有服务器都是唯一的，即所有的事务和所有的GTID都是1对1的映射。
当在主库上提交事务或者被从库应用时，可以定位和追踪每一个事务，对DBA来说意义就很大了，我们可以适当的解放出来，不用手工去可以找偏移量的值了，而是通过CHANGE MASTER TO MASTER_HOST='xxx', MASTER_AUTO_POSITION=1的即可方便的搭建从库，在故障修复中也可以采用MASTER_AUTO_POSITION=‘X’的方式。
5.7版本GTID做了增强，不手工开启也自动维护匿名的GTID信息
一个GTID的生命周期
1.事务在主库上执行并提交给事务分配一个gtid（由主库的uuid和该服务器上未使用的最小事务序列号），该GTID被写入到binlog中。
2.备库读取relaylog中的gtid，并设置session级别的gtid_next的值，以告诉备库下一个事务必须使用这个值
3.备库检查该gtid是否已经被其使用并记录到他自己的binlog中。slave需要担保之前的事务没有使用这个gtid，也要担保此时已分读取gtid，但未提交的事务也不恩呢过使用这个gtid.
4.由于gtid_next非空，slave不会去生成一个新的gtid，而是使用从主库获得的gtid。这可以保证在一个复制拓扑中的同一个事务gtid不变。由于GTID在全局的唯一性，通过GTID，我们可以在自动切换时对一些复杂的复制拓扑很方便的提升新主库及新备库，例如通过指向特定的GTID来确定新备库复制坐标。
基于GTID部署主从复制
注意：
🔊 主库和从库都要开启binlog
🔊 主库和从库server-id必须不同
🔊 要有主从复制用户
主库 192.168.15.204
[mysqld]
...
server-id=204
binlog_format=row
log-bin=mysql-bin
skip-name-resolve # 跳过域名解析（非必须）
gtid-mode=on # 启用gtid类型，否则就是普通的复制架构
enforce-gtid-consistency=true #强制GTID的一致性
log-slave-updates=1 # slave更新是否记入日志（5.6必须的）
relay_log_purge = 0 # 关闭relay_log自动清除功能，保障故障时的数据一致
从库192.168.15.201
[mysqld]
...
server-id=201
binlog_format=row
log-bin=mysql-bin
skip-name-resolve
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
relay_log_purge=0
主库创建复制账户
mysql> GRANT REPLICATION SLAVE ON *.* TO baim0@'%' IDENTIFIED BY 'Zkh0928!';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> flush privileges;
两个从库开启复制
change master to
master_host='192.168.15.204',
master_user='baim0',
master_password='Zkh0928!',
MASTER_AUTO_POSITION=1;
制作双主
# 找一台从库，假设为192.168.15.101，在该主机上创建账号
GRANT REPLICATION SLAVE ON *.* TO baim0@'%' IDENTIFIED BY '123';
flush privileges;
# 在主库上执行下述操作，指向从库192.168.15.101
change master to
master_host='192.168.15.101',
master_user='baim0',
master_password='123',
MASTER_AUTO_POSITION=1;
# 开启主库的slave
start slave;
跳过事务
传统的复制例，如果主从复制遇到了某条sql错误，SQL停了，我们可以通过下述操作跳过错误
stop slave;
set global sql_slave_skip_counter=1;
start slave;
在传统的主从里，counter=1是跳过一条sql，而GTID是基于事务的主从复制，如果跳过就是跳过一整个事务，所以上述方法并不适用于GTID
#跳过事务的方法：
1)停止slave进程
mysql> STOP SLAVE;
2)设置事务号，执行show slave status\G查看Retrieved_Gtid_Set的值即事务号
在session里设置gtid_next，即跳过这个GTID
mysql> SET GTID_NEXT= '6d257f5b-5e6b-11e8-b668-5254003de1b6:1'
3)设置空事物
mysql> BEGIN; COMMIT;
4)恢复事物号
mysql> SET SESSION GTID_NEXT = AUTOMATIC;
5)启动slave进程
mysql> START SLAVE;
部署MHA
环境准备
| 服务器 | ip |
|---|---|
| node1 | 192.168.15.201 |
| node2 | 192.168.15.202 |
| mannger | 192.168.15.203 |
| master | 192.168.15.204 |
-
1、所有数据库服务器都需要开启binlog日志
-
2、所有数据库都需要有主从复制的用户（授权复制权限）
GRANT REPLICATION SLAVE ON *.* TO baim0@'%' IDENTIFIED BY 'Zkh0928!'; flush privileges; -
需要在主库上创建一个管理用户用于日后的MHA管理（授权所有权限）
# 在主库上执行即可，从库会同步过去 grant all on *.* to 'mhaadmin'@'%' identified by 'Zkh0928!'; flush privileges; -
MHA对MySQL复制环境有特殊的要求
开启二进制日志及中继日志 各个“slave节点”必须显式启用3其`read-only`属性 关闭`relay_log_purge`功能#1、在从库上进行操作 #设置只读,不要添加配置文件,因为从库以后可能变成主库 mysql> set global read_only=1; #2、在所有库上都进行操作（这一步我们在5.3小节已经做过了，此处忽略即可） #关闭MySQL自动清除relaylog的功能 mysql> set global relay_log_purge = 0; #编辑配置文件 [root@mysql-db02 ~]# vim /etc/my.cnf [mysqld] #禁用自动删除relay log永久生效 relay_log_purge = 0
配置免密登录（所有主机之间都要做）
#!/usr/bin/env bash
ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa >/dev/null 2>&1
yum install expect -y
for i in 201 202 203 204;
do
expect << EOF
spawn ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.15.$i
expect {
"yes/no" {send "yes\r";exp_continue}
"*assword" {send "123\n"}
}
expect eof
EOF
done
安装软件包
所有机器安装依赖
# 安装yum源
wget http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
rpm -ivh epel-release-latest-7.noarch.rpm
# 安装MHA依赖的perl包
yum install -y perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager
# 安装node包
wget https://qiniu.wsfnk.com/mha4mysql-node-0.58-0.el7.centos.noarch.rpm --no-check-certificate
rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm
mannager主机安装mannager包
wget https://qiniu.wsfnk.com/mha4mysql-manager-0.58-0.el7.centos.noarch.rpm --no-check-certificate
rpm -ivh mha4mysql-manager-0.58-0.el7.centos.noarch.rpm
配置MHA manager
创建工作目录
mkdir -p /service/mha/
mkdir /service/mha/app1
修改配置
[server default]
#日志存放路径
manager_log=/service/mha/manager.log
#定义工作目录位置
manager_workdir=/service/mha/app1
#设置ssh的登录用户名
ssh_user=root
ssh_port=22
#管理用户
user=mhaadmin
password=Zkh0928!
#复制用户
repl_user=baim0
repl_password=Zkh0928!
# 心跳检测
ping_interval=1
[server1]
master_binlog_dir=/var/lib/mysql
hostname=192.168.15.201
port=3306
[server2]
candidate_master=1
check_repl_delay=0
master_binlog_dir=/var/lib/mysql
hostname=192.168.15.202
port=3306
[server3]
master_binlog_dir=/var/lib/mysql
hostname=192.168.15.204
port=3306
# 2、上述两个参数详解如下：
# 设置参数candidate_master=1后，则判断该主机为为候选master，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件最新的slave。
# 默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master
# 3、应该为什么节点设置这俩参数，从而把该节点的优先级调高
# （1）、多地多中心，设置本地节点为高权重
# （2）、在有半同步复制的环境中，设置半同步复制节点为高权重
# （3）、你觉着哪个机器适合做主节点，配置较高的 、性能较好的
检测MHA配置状态
#测试免密连接
1.使用mha命令检测ssh免密登录
masterha_check_ssh --conf=/service/mha/app1.cnf
ALL SSH ... successfilly 表示ok了
2.使用mha命令检测主从状态
masterha_check_repl --conf=/service/mha/app1.cnf
... Health is OK
#如果出现问题，可能是反向解析问题，配置文件加上
skip-name-resolve
#还有可能是主从状态，mha用户密码的情况
启动MHA
nohup masterha_manager --conf=/service/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /service/mha/manager.log 2>&1 &
命令参数：
--remove_dead_master_conf 该参数代表当发生主从切换后，宕机库的配置信息将会从配置文件中移除。
--manger_log 日志存放位置
--ignore_last_failover 在缺省情况下，如果MHA检测到连续发生宕机，且两次宕机间隔不足8小时的话，则不会进行Failover，之所以这样限制是为了避免ping-pong效应。该参数代表忽略上次MHA触发切换产生的文件，默认情况下，MHA发生切换后会在日志目录，也就是上面设置的manager_workdir目录中产生app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为--ignore_last_failover。
#MHA的安全机制:
1.完成一次切换后,会生成一个锁文件在工作目录中
2.下次切换之前,会检测锁文件是否存在
3.如果锁文件存在,8个小时之内不允许第二次切换
测试自动切换与恢复
#查看日志
tail -f /service/mha/manager.log
#停掉主库master
[root@db01 ~]# systemctl stop mysql
# 1、修复结束
[root@master ~]# systemctl start mysqld
#2.将宕机的库作为从库指向新主库，此时为'192.168.15.102'，可以通过查看日志文件确认新主库地址: grep -i 'change master to' /service/mha/manager.log
change master to
master_host='192.168.15.204',
master_user='baim0',
master_password='Zkh0928!',
MASTER_AUTO_POSITION=1;
start slave;
show slave status;
# 3.如果启动manager时加入了参数--remove_dead_master_conf ，则此处需要将修复后的数据库信息配置到文件中
vim /service/mha/app1.cnf
[server1]
# 指定自己的binlog日志存放目录
master_binlog_dir=/var/lib/mysql
hostname=192.168.15.100
port=3306
# 4.再次启动MHA（故障迁移一次masterha_manager就结束了，所以故障库修复后需要重新启动）
nohup masterha_manager --conf=/service/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /service/mha/manager.log 2>&1 &
# 5.检测MHA启动状态
masterha_check_status --conf=/service/mha/app1.cnf
配置vip自动漂移脚本
vip漂移的两种方式
1）通过keepalived的方式，管理虚拟IP的漂移
2）通过MHA自带脚本方式，管理虚拟IP的漂移(推荐)
为了防止脑裂发生,推荐生产环境采用脚本的方式来管理虚拟vip,而不是使用 keepalived来完成。
配置文件中指定脚本路径
[root@mysql-db03 ~]# vim /service/mha/app1.cnf
[server default]
#指定自动化切换主库后，执行的vip迁移脚本路径
master_ip_failover_script=/service/mha/master_ip_failover
编写jio本
vim /service/mha/master_ip_failover
# 注意脚本以下几行
# 要求所有数据库网卡名必须一致
my $vip = '192.168.15.250/24';# 配置虚拟的ip
my $key = '1';# 虚拟网卡编号
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";# 注意网卡名必须都一致eth0
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down"; # 注意网卡名必须都一致eth0
# 注意给脚本要添加执行权限否则mha会无法启动
#!/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
);
#定义VIP变量
my $vip = '192.168.15.250/24';
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" ) {
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";
}
手动绑定vip到主库
# 强调：先执行一下ssh root@192.168.15.250，把yes输入一下，退出后
# 再执行下述脚本
for i in `seq 1 1000000`
do
ssh root@192.168.15.250 "mysql -e 'insert into test.t1 values($i);'"
sleep 1
echo "$i ok"
done
# ssh到主库所在服务器，然后执行
ifconfig eth0:1 192.168.15.250/24 # 注意与脚本中对应eth0:1
# 关闭数据库模拟宕机
systemctl stop mysqld
# 查看另一台机器的vip是否漂移成功
[root@master ~]# ip a | grep 250
inet 192.168.15.250/24 brd 192.168.15.255 scope global secondary eth0:1
配置vip手动切换主从脚本
配置脚本的路径
vim /service/mha/app1.cnf
[server default]
......
#指定手动切换主库后，执行的vip迁移脚本路径
master_ip_online_change_script="/service/mha/master_online_change"
编写手动切换主库后的vip迁移脚本
vim /service/mha/master_online_change
#!/bin/bash
source /root/.bash_profile
vip=`echo '192.168.15.250/24'` #设置VIP
key=`echo '1'`
command=`echo "$1" | awk -F = '{print $2}'`
orig_master_host=`echo "$2" | awk -F = '{print $2}'`
new_master_host=`echo "$7" | awk -F = '{print $2}'`
orig_master_ssh_user=`echo "${12}" | awk -F = '{print $2}'`
new_master_ssh_user=`echo "${13}" | awk -F = '{print $2}'`
#要求服务的网卡识别名一样，都为eth0(这里是)
stop_vip=`echo "ssh root@$orig_master_host /usr/sbin/ifconfig eth0:$key down"`
start_vip=`echo "ssh root@$new_master_host /usr/sbin/ifconfig eth0:$key $vip"`
if [ $command = 'stop' ]
then
echo -e "\n\n\n****************************\n"
echo -e "Disabled thi VIP - $vip on old master: $orig_master_host \n"
$stop_vip
if [ $? -eq 0 ]
then
echo "Disabled the VIP successfully"
else
echo "Disabled the VIP failed"
fi
echo -e "***************************\n\n\n"
fi
if [ $command = 'start' -o $command = 'status' ]
then
echo -e "\n\n\n*************************\n"
echo -e "Enabling the VIP - $vip on new master: $new_master_host \n"
$start_vip
if [ $? -eq 0 ]
then
echo "Enabled the VIP successfully"
else
echo "Enabled the VIP failed"
fi
echo -e "***************************\n\n\n"
fi
# 添加执行权限
chmod +x /service/mha/master_online_change
# 手动绑定vip到主库
ifconfig eth0:1 192.168.15.250
手动切换主库验证vip漂移
# 先停掉mha
masterha_stop --conf=/service/mha/app1.cnf
# 将主库切换到192.168.15.101
masterha_master_switch --conf=/service/mha/app1.cnf --master_state=alive --new_master_host=192.168.15.101 --orig_master_is_new_slave --running_updates_limit=10000 --interactive=0
binlog备份
如果主库断电或者断网的时候，实时保存binlog
前期准备
准备一台新的mysql实例，与主库板块一致，GTID必须开启
然后改mysql主机就用于实时拉取主库的binlog，并不与主库同步，只是用来拉取主库的binlog，防止主库突然断电
停止MHA
masterha_stop --conf=/service/mha/app1.cnf
创建binlog存放目录并设置权限
mkdir -p /bak/binlog/
chown -R mysql.mysql /bak/binlog
手动执行备份binlog
cd /bak/binlog
# 查看所有从库show slave status\G
mysqlbinlog -R --host=主库ip地址 --user=mhaadmin --password=666 --raw --stop-never mysql-bin.000002 &
# 注意：写成mysql-bin.000002则会从该文件开始拉取一直到最新的
mysqlbinlog -R --host=192.168.15.204 --user=mhaadmin --password=Zkh0928! --raw --stop-never mysql-bin.000002 &
在app1.cnf开启binlogserver功能
...
[binlog1]
no_master=1
# binlogserver主机的ip地址
hostname=192.168.15.102
# 不能跟当前机器数据库的binlog存放目录一样
master_binlog_dir=/bak/binlog/
# 这里有个坑要注意，这个配置文件里每个ip都是唯一的
验证主库验证
mysql> flush logs; -- 看到binlogserver主机上/bak/binlog目录下新增日志
再次启动
nohup masterha_manager --conf=/service/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /service/mha/manager.log 2>&1 &
常用命令汇总
#1、重置slave
stop slave;
reset slave;
#2、查看
SHOW SLAVE STATUS; #查看从库复制状态
SHOW MASTER STATUS; #查看当前binlog位点
SHOW SLAVE HOSTS; #查看从库列表
#3、重做slave指向主库
stop slave;
CHANGE MASTER TO MASTER_HOST='192.168.15.100', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='egon', MASTER_PASSWORD='123';
start slave;
#4、停止mha
masterha_stop --conf=/service/mha/app1.cnf
#5、查看ssh与主从状态
masterha_check_ssh --conf=/service/mha/app1.cnf
masterha_check_repl --conf=/service/mha/app1.cnf
#6、启动mha
nohup masterha_manager --conf=/service/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /service/mha/manager.log 2>&1 &
#7、查看mha状态
masterha_check_status --conf=/service/mha/app1.cnf
#8、修改mha配置文件
cat >> /service/mha/app1.cnf << EOF
[server default]
manager_log=/service/mha/manager.log
manager_workdir=/service/mha/app1
master_ip_failover_script=/service/mha/master_ip_failover
master_ip_online_change_script="/service/mha/master_online_change"
password=666
ping_interval=1
repl_password=123
repl_user=egon
ssh_port=22
ssh_user=root
user=mhaadmin
[server1]
hostname=192.168.15.100
master_binlog_dir=/var/lib/mysql
port=3306
[server2]
hostname=192.168.15.101
master_binlog_dir=/var/lib/mysql
port=3306
[server3]
hostname=192.168.15.102
master_binlog_dir=/var/lib/mysql
port=3306
EOF
