1. 主从复制架构演变介绍
1.1 基本结构
（1）一主一从
（2）一主多从
（3）多级主从
（4）双主
（5）循环复制
1.2 高级应用架构演变
1.2.1 高性能架构
读写分离架构(读性能较高)
代码级别
MySQL proxy (Atlas,mysql router,proxySQL(percona),maxscale)、
amoeba(taobao)
xx-dbproxy等。
分布式架构(读写性能都提高):
分库分表——cobar--->TDDL(头都大了),DRDS
Mycat--->DBLE自主研发等。
NewSQL-->TiDB
1.2.2 高可用架构
（3）单活:MMM架构——mysql-mmm（google）
（4）单活:MHA架构——mysql-master-ha（日本DeNa）,T-MHA
（5）多活:MGR ——5.7 新特性 MySQL Group replication(5.7.17) --->Innodb Cluster
（6）多活:MariaDB Galera Cluster架构,(PXC)Percona XtraDB Cluster、MySQL Cluster(Oracle rac)架构
2. 高可用MHA *****
2.1 MHA架构工作原理
主库宕机处理过程
1. 监控节点 (通过配置文件获取所有节点信息) ---mysqladmin ping
系统,网络,SSH连接性------ssh 10.0.0.51 hostname
主从状态,重点是主库
2. 选主
(1) 如果判断从库(position或者GTID),数据有差异,最接近于Master的slave,成为备选主
(2) 如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主.
(3) 如果设定有权重(candidate_master=1),按照权重强制指定备选主.
1. 默认情况下如果一个slave落后master 100M的relay logs的话，即使有权重,也会失效.
2. 如果check_repl_delay=0的话,即使落后很多日志,也强制选择其为备选主
3. 数据补偿
(1) 当SSH能连接,从库对比主库GTID 或者position号,立即将二进制日志保存至各个从节点并且应用(save_binary_logs )
从库：show slave status \G
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 730
主库：show master status
+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000002 | 730 | | | 56c6b8a8-da29-11eb-b68d-000c295250b5:1-2 |
+------------------+----------+--------------+------------------+------------------------------------------+
从库：Retrieved_Gtid_Set: 56c6b8a8-da29-11eb-b68d-000c295250b5:1-2
Executed_Gtid_Set: 56c6b8a8-da29-11eb-b68d-000c295250b5:1-2
主库：show master status
(2) 当SSH不能连接, 对比从库之间的relaylog的差异(apply_diff_relay_logs)
4. Failover（masterha_master_switch）
5. 故障的节点踢出集群（masterha_conf_host ）
将备选主进行身份切换,对外提供服务
其余从库和新主库确认新的主从关系（change master to start slave ）
6. 应用透明(VIP)
7. 故障切换通知(send_reprt)
8. 二次数据补偿(binlog_server)
9. 自愈自治(待开发...)
补充
- candidate_master=1的应用？
设置为候选master，如果设置参数以后，发生主从切换以后将会将从库提升为主库，即使这个主库不是集群中时间最新的slave
作用：设置权重
应用场景？
两地三中心
设有keepalived实现VIP
2.check_repl_delay=0的应用？
默认情况下如果一个slave落后master 100M的relay log的话
MHA将不会选择该slave作为一个新的master，因为对于这个slave恢复需要很长时间，通过设置.check_repl_delay=0 MHA触发
切换在选择一个新的master的时候将会忽略复制延迟，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的时候一定是一个新的master
2.2 架构介绍:
1主2从，master：db01 slave：db02 db03 ）：
MHA 高可用方案软件构成
Manager软件：选择一个从节点安装
Node软件：所有节点都要安装
2.3 MHA软件构成
Manager工具包主要包括以下几个工具：（db03）
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信息
masterha_stop 关闭manager
Node工具包主要包括以下几个工具：（所有节点）
这些工具通常由MHA Manager的脚本触发，无需人为操作
save_binary_logs 保存和复制master的二进制日志
apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs 清除中继日志（不会阻塞SQL线程）
2.4 MHA环境搭建
2.4.1 规划:
主库: 51 node
从库:
52 node
53 node manager
2.4.2 准备环境（略。1主2从GTID）
GTID核心参数
重要参数：
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
gtid-mode=on --启用gtid类型，否则就是普通的复制架构
enforce-gtid-consistency=true --强制GTID的一致性
log-slave-updates=1 --slave更新是否记入日志
意思就是强制从库也记录二进制日志
GTID复制配置过程：
清理环境
准备三台机器(克隆）
vim /etc/hosts
hostnamectl set-hostname db01
hostnamectl set-hostname db02
hostnamectl set-hostname db03
清理环境（三台）
避免与之前环境有影响
[root@db01 3307]# pkill mysqld
[root@db01 3307]# \rm -rf /data/mysql/data/*
[root@db01 3307]# \rm -rf /data/binlog/*
[root@db01 data]# mkdir -p /data/mysql/data
[root@db01 data]# mkdir -p /data/mysql/binlog
[root@db01 data]# chown -R mysql.mysql /data/*
准备配置文件
把之前的配置文件备份
主库
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/app/mysql/
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=51
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/mysql/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db01 [\\d]>
EOF
从库db02
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/app/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=52
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/mysql/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db02 [\\d]>
EOF
从库db03
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/app/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=53
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/mysql/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db03 [\\d]>
EOF
初始化数据
三台都初始化
mysqld --initialize-insecure --user=mysql --basedir=/app/mysql --datadir=/data/mysql/data
启动数据库
/etc/init.d/mysqld start
查看：
[root@db01 ~]# mysql -e ‘select @@server_id’
±------------+
| @@server_id |
±------------+
| 51 |
±------------+
[root@db02 mysql]# mysql -e ‘select @@server_id’
±------------+
| @@server_id |
±------------+
| 52 |
±------------+
[root@db03 ~]# mysql -e ‘select @@server_id’
±------------+
| @@server_id |
±------------+
| 53 |
±------------+
构建主从：
master:51（主库）
slave:52,53
51:
grant replication slave on *.* to repl@'10.0.0.%' identified by '123';
52\53:
change master to
master_host='10.0.0.51',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;
start slave;
2.4.3 配置关键程序软连接
三台
ln -s /app/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /app/mysql/bin/mysql /usr/bin/mysql
2.4.4 配置各节点互信
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
或者：
[root@db01 ~]# ssh-keygen
[root@db01 ~]# ssh-copy-id -i .ssh/id_rsa.pub root@10.0.0.53
[root@db01 ~]# ssh-copy-id -i .ssh/id_rsa.pub root@10.0.0.52
各节点验证
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
2.4.5 安装软件
下载mha软件
mha官网：https://code.google.com/archive/p/mysql-master-ha/
github下载地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads
所有节点安装Node软件依赖包
MHA是由perl编写的，所以要安装perl语言环境
yum install perl-DBD-MySQL -y
安装
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
补充：源码包安装Node软件
创建目录
[root@db03 bin]# mkdir /usr/local/packages
[root@db03 bin]# cd /usr/local/packages
上传包
[root@db03 packages]# rz -E
rz waiting to receive.
[root@db03 packages]# ll
总用量 52
-rw-r–r-- 1 root root 50172 3月 5 18:27 mha4mysql-node-0.56.tar.gz
解压包
[root@db03 packages]# tar xf mha4mysql-node-0.56.tar.gz
[root@db03 packages]# ll
总用量 52
drwxr-xr-x 8 4984 users 168 4月 1 2014 mha4mysql-node-0.56
-rw-r–r-- 1 root root 50172 3月 5 18:27 mha4mysql-node-0.56.tar.gz
[root@db03 packages]# cd mha4mysql-node-0.56/
编译安装
[root@db03 mha4mysql-node-0.56]# perl Makefile.PL
有报错：
*** Module::AutoInstall version 1.03
*** Checking for Perl dependencies…
Can’t locate CPAN.pm in @INC (@INC contains: inc /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at inc/Module/AutoInstall.pm line 277.
需要安装 perl-CPAN模块
[root@db03 mha4mysql-node-0.56]# yum -y install perl-CPAN
重新安装
[root@db03 mha4mysql-node-0.56]# perl Makefile.PL
编译安装
[root@db03 mha4mysql-node-0.56]# make && make install
在db01主库中创建mha需要的用户
grant all privileges on *.* to mha@'10.0.0.%' identified by '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主节点安装manager管理服务
安装mha4mysql-manager管理服务
1）解压、安装
中间若有提示，全都接受，过程大约十分钟
[root@db03 ~]# cd /usr/local/packages
[root@localhost packages]# rz
[root@localhost packages]# tar -xvf mha4mysql-manager-0.56.tar.gz
[root@localhost packages]# cd mha4mysql-manager-0.56
[root@localhost mha4mysql-manager-0.56]# perl Makefile.PL
[root@localhost mha4mysql-manager-0.56]# make && make install
manager安装后在/usr/local/bin下面会生成几个工具，主要包括以下几个：
masterha_check_ssh # 检查 MHA 的 SSH 配置状况
masterha_check_repl # 检查 MySQL 复制状况
masterha_manger # 启动 manager的脚本
masterha_check_status # 检测当前 MHA 运行状态
masterha_master_monitor # 检测 master 是否宕机
masterha_master_switch # 控制故障转移（自动或者手动）
masterha_conf_host # 添加或删除配置的 server 信息
masterha_stop # 关闭manager
2.4.6 配置文件准备(db03)
创建配置文件目录
mkdir -p /etc/mha
创建日志目录
mkdir -p /var/log/mha/app1
编辑mha配置文件
vim /etc/mha/app1.cnf
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog
user=mha
password=mha
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root
[server1]
hostname=10.0.0.51
port=3306
[server2]
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=3306
配置文件的解释：
vim /etc/mha/app1.cnf
[server default] ------- 所有的节点都受用
manager_log=/var/log/mha/app1/manager --------- manager工作产生的日志信息
manager_workdir=/var/log/mha/app1 ----存放日志的地方
master_binlog_dir=/data/binlog -------主库二进制位置点
user=mha -----mha专业的用户
password=mha -----mha专业用户的密码
ping_interval=2 -----探测节点状态的时间间隔为2秒，一共ping3次
repl_password=123 -----主从复制的密码
repl_user=repl -------主从复制的用户
ssh_user=root -----当前ssh连接时的用户
[server1] —以下为节点的信息
hostname=10.0.0.51
port=3306
[server2]
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=3306
2.4.7 状态检查
互信检查
### 互信检查
masterha_check_ssh --conf=/etc/mha/app1.cnf
......
Fri Apr 19 16:39:35 2019 - [debug]
Fri Apr 19 16:39:34 2019 - [debug] Connecting via SSH from root@10.0.0.51(10.0.0.51:22) to root@10.0.0.52(10.0.0.52:22)..
Fri Apr 19 16:39:34 2019 - [debug] ok.
Fri Apr 19 16:39:34 2019 - [debug] Connecting via SSH from root@10.0.0.51(10.0.0.51:22) to root@10.0.0.53(10.0.0.53:22)..
root@10.0.0.51(10.0.0.51:22)..
Fri Apr 19 16:39:35 2019 - [debug] ok.
Fri Apr 19 16:39:35 2019 - [debug] Connecting via SSH from root@10.0.0.53(10.0.0.53:22) to root@10.0.0.52(10.0.0.52:22)..
Fri Apr 19 16:39:36 2019 - [debug] ok.
Fri Apr 19 16:39:37 2019 - [info] All SSH connection tests passed successfully.
......
主从状态检查
[root@db03 ~] masterha_check_repl --conf=/etc/mha/app1.cnf
.......
Fri Apr 19 16:39:36 2019 - [debug]
Fri Apr 19 16:39:35 2019 - [debug] Connecting via SSH from root@10.0.0.52(10.0.0.52:22) to root@10.0.0.51(10.0.0.51:22)..
Fri Apr 19 16:39:35 2019 - [debug] ok.
Fri Apr 19 16:39:35 2019 - [debug] Connecting via SSH from root@10.0.0.52(10.0.0.52:22) to root@10.0.0.53(10.0.0.53:22)..
Fri Apr 19 16:39:35 2019 - [debug] ok.
Fri Apr 19 16:39:37 2019 - [debug]
Fri Apr 19 16:39:35 2019 - [debug] Connecting via SSH from root@10.0.0.53(10.0.0.53:22) to root@10.0.0.51(10.0.0.51:22)..
......
2.4.8 开启MHA(db03)：
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
2.4.9 查看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 |
+---------------+-------+
2.4.10 故障模拟及处理
### 停主库db01:
/etc/init.d/mysqld stop
[root@db01 mysql]# pkill mysqld
###2.查看db02是不是主库
db03 [(none)]>show slave status \G
Master_Host: 10.0.0.52
Executed_Gtid_Set: 56c6b8a8-da29-11eb-b68d-000c295250b5:1-2
###查看db03
db02 [(none)]>show slave status \G
###查看日志
观察manager 日志 tail -f /var/log/mha/app1/manager
末尾必须显示successfully，才算正常切换成功。
修复主库
[root@db01 ~]# /etc/init.d/mysqld start
恢复主从结构
现在主库是db02-10.0.0.51
CHANGE MASTER TO
MASTER_HOST='10.0.0.52',
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1,
MASTER_USER='repl',
MASTER_PASSWORD='123';
start slave ;
或者日志里面
[root@db03 ~]# cat /var/log/mha/app1/manager
CHANGE MASTER TO MASTER_HOST='10.0.0.52', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='123';
start slave
修改配置文件
[root@db03 mysql]# vim /etc/mha/app1.cnf
[server1]
hostname=10.0.0.51
port=3306
启动MHA
[root@db03 mysql]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
#检查启动状态
[root@db03 mysql]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:9210) is running(0:PING_OK), master:10.0.0.52
补充：
生产中经需要注意的问题？
看还得程度
如果完全坏了就得重新搭建主从
先备份
在构建从库
再重新change master to
2.4.11 Manager额外参数介绍
说明：
主库宕机谁来接管？
1. 所有从节点日志都是一致的，默认会以配置文件的顺序去选择一个新主。
2. 从节点日志不一致，自动选择最接近于主库的从库
3. 如果对于某节点设定了权重（candidate_master=1），权重节点会优先选择。
但是此节点日志量落后主库100M日志的话，也不会被选择。可以配合check_repl_delay=0，关闭日志量的检查，强制选择候选节点。
(1) ping_interval=1
#设置监控主库，发送ping包的时间间隔，尝试三次没有回应的时候自动进行failover
(2) candidate_master=1
#设置为候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件最新的slave
(3)check_repl_delay=0
#默认情况下如果一个slave落后master 100M的relay logs的话，
MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master
2.4.12 MHA manager 的vip功能
参数
master_ip_failover_script=/usr/local/bin/master_ip_failover
注意：/usr/local/bin/master_ip_failover，必须事先准备好
MHA VIP的调用脚本
#!/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.0.55/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";
}
修改脚本内容
vi /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";
脚本文件的解释
vi /usr/local/bin/master_ip_failover
##VIP必须与对外提供服务的是同一网段，并且不能被占用
my $vip = ‘10.0.0.55/24’;
##以eth0：什么结尾
my $key = ‘1’;
启动
my s s h s t a r t v i p = " / s b i n / i f c o n f i g e t h 0 : ssh_start_vip = "/sbin/ifconfig eth0: sshstartvip="/sbin/ifconfigeth0:key $vip";
停止
my s s h s t o p v i p = " / s b i n / i f c o n f i g e t h 0 : ssh_stop_vip = "/sbin/ifconfig eth0: sshstopvip="/sbin/ifconfigeth0:key down";
更改manager配置文件：
vi /etc/mha/app1.cnf
添加：
master_ip_failover_script=/usr/local/bin/master_ip_failover
注意：
[root@db03 ~]# dos2unix /usr/local/bin/master_ip_failover
dos2unix: converting file /usr/local/bin/master_ip_failover to Unix format ...
[root@db03 ~]# chmod +x /usr/local/bin/master_ip_failover
主库上，手工生成第一个vip地址
手工在主库上绑定vip，注意一定要和配置文件中的ethN一致，我的是eth0:1(1是key指定的值)
ifconfig eth0:1 10.0.0.55/24
#如果没有ifconfig命令
yum install net-tools -y
重启mha-manager
#停止MHA
masterha_stop --conf=/etc/mha/app1.cnf
#启动MHA
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
检查状态
masterha_check_status --conf=/etc/mha/app1.cnf
测试
1.目前VIP在db01-10.0.0.51上
[root@db01 ~]# ifconfig eth0:1 10.0.0.55/24
[root@db01 ~]# ip a
inet 10.0.0.55/24 brd 10.0.0.255 scope global secondary eth0:1
2停掉主库的数据库
[root@db01 ~]# /etc/init.d/mysqld stop
Shutting down MySQL… SUCCESS!
3.观察的现象
VIP自动飘逸到db02上
db03的MHA manager 停掉
配置文件里面DB01的节点信息剔除
db03的主库为db02
2.4.13 邮件提醒
1. 参数：
report_script=/usr/local/bin/send
2. 准备邮件脚本
send_report
(1)准备发邮件的脚本(上传 email_2019-最新.zip中的脚本，到/usr/local/bin/中)
(2)将准备好的脚本添加到mha配置文件中,让其调用
3. 修改manager配置文件，调用邮件脚本
vi /etc/mha/app1.cnf
report_script=/usr/local/bin/send
（3）停止MHA
masterha_stop --conf=/etc/mha/app1.cnf
（4）开启MHA
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
(5) 关闭主库,看警告邮件
故障修复：
1. 恢复故障节点
（1）实例宕掉
/etc/init.d/mysqld start
（2）主机损坏，有可能数据也损坏了
备份并恢复故障节点。
2.恢复主从环境
看日志文件：
CHANGE MASTER TO MASTER_HOST='10.0.0.52', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='123';
start slave ;
3.恢复manager
3.1 修好的故障节点配置信息，加入到配置文件
[server1]
hostname=10.0.0.51
port=3306
3.2 启动manager
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
2.4.14 binlog server（db03）
参数：
binlogserver配置：
找一台额外的机器，必须要和原库版本一致，支持gtid并开启，我们直接用的第二个slave（db03）
vim /etc/mha/app1.cnf
[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/binserver
配置文件解释
vim /etc/mha/app1.cnf
节点
[binlog1]
不会被选主
no_master=1
#binlog server的位置
hostname=10.0.0.53
#一定不能和原来的位置一样，重新定义一个新的二进制日志存放
master_binlog_dir=/data/binserver
创建必要目录
mkdir -p /data/binserver
chown -R mysql.mysql /data/*
修改完成后，将主库binlog拉过来（从000001开始拉，之后的binlog会自动按顺序过来）
拉取主库binlog日志
cd /data/binserver -----》必须进入到自己创建好的目录
mysqlbinlog -R --host=10.0.0.51 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &
注意：
拉取日志的起点,需要按照目前从库的已经获取到的二进制日志点为起点
从库执行命令：show slave status \G
依据这个 Master_Log_File: mysql-bin.000003
命令解释
mysqlbinlog -R --host=10.0.0.51 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &
–host ：代表主库
–user ：用户
–password：密码
mysql-bin.000001:可以从从库中看见已经调取过来的master日志的编号
重启MHA
#停止MHA
masterha_stop --conf=/etc/mha/app1.cnf
#开启MHA
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &
故障处理
主库宕机，binlogserver 自动停掉，manager 也会自动停止。
处理思路：
1、重新获取新主库的binlog到binlogserver中
2、重新配置文件binlog server信息
3、最后再启动MHA
3.管理员在高可用架构维护的职责
1. 搭建：MHA+VIP+SendReport+BinlogServer
2. 监控及故障处理
3. 高可用架构的优化
核心是：尽可能降低主从的延时，让MHA花在数据补偿上的时间尽量减少。
5.7 版本，开启GTID模式，开启从库SQL并发复制。
扫一扫
216
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
