1、MHA高可用
1.1 高级应用架构演变
1、基本结构
（1）一主一从
（2）一主多从
（3）多级主从
（4）双主
（5）循环复制
2、高级应用架构演变
高性能架构
（1）读写分离中间件——MySQL proxy（atlas，mysql router，proxySQL，maxscale）、amoeba、xx-dbproxy等。
（2）分布式架构：分库分表——cobar、Mycat，自主研发等。高可用架构
（3）单活：MMM架构——mysql-mmm(google)
（4）单活：MHA架构——mysql-master-ha（日本DeNa）
（5）多活：MGR（未来趋势）——5.7 新特性MySQL Group replication
（6）多活：PXC、MySQL Cluster架构
2.2 MHA介绍
1、MHA工作原理
manager节点通过mha专用用户，监控所有主从节点
系统,网络,SSH连接性
主从状态,重点是主库根据配置策略选主
(1) 如果判断从库(position或者GTID),数据有差异,最接近于Master的slave,成为备选主
(2) 如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主.
(3) 如果设定有权重，按照权重强制指定备选主库candidate_master=1
check_repl_delay=0数据补偿
(1) 当SSH能连接原主库，从库对比主库GTID 或者position号，找出缺失部分的事务，立即将二进制日志保存至各个从节点/tmp目录下(save_binary_logs )，并且所有从库都立即补偿缺失部分数据。
s1从库：
stop slave;
reset slave all; //清除所有原从库信息
s2从库：
stop slave;
reset slave all; //清除所有原从库信息
两个从库数据一致，s2从库 change master to s1 从库
(2) 当SSH不能连接原主库, 对比从库之间的relaylog的差异(apply_diff_relay_logs) ，s2从库应用差异日志
s1从库：
stop slave;
reset slave all; //清除所有原从库信息
s2从库：
stop slave;
reset slave all; //清除所有原从库信息
两个从库数据一致，s2从库 change master to s1 从库vip 会切换到新的主库，实现应用透明。
manager 做完以上操作后，自动关闭，清理掉配置文件中的故障节点信息。
2、架构介绍
1主2从，master：db01 slave：db02 db03
必须是独立节点，不支持多实例。
3、MHA 高可用方案软件构成
Manager软件：选择一个从节点安装(主节点除外)
Node软件：所有节点都要安装
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线程）
2、MHA环境搭建
2.1 规划
主库: 51 node
从库: 52 node
53 node manager
2.2 环境准备（略。1主2从GTID复制，上文有）
- MHA上不能搭建过滤复制
2.3 搭建前准备
1、设置relay-log的自动删除功能，从库设置只读
# 临时关闭自动清除relay log功能（所有库）
set global relay_log_purge = 0;
# 永久关闭自动清除relay log功能（所有库
[root@db01 data]# vim /etc/my.cnf
[mysqld]
relay_log_purge = 0
# 临时开启只读功能（所有从库）
set global read_only=1;
2、配置关键程序软连接(所有库)
ln -s /data/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /data/mysql/bin/mysql /usr/bin/mysql
3、配置各节点互信
# 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
4、在db01主库中创建mha需要的用户
grant all privileges on *.* to mha@'10.0.0.%' identified by 'mha';
2.4 下载MHA软件
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
# db03 安装manager软件
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
2.5 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/mysql/
user=mha
password=mha
ping_interval=2 //2秒种连接一次主库
repl_password=123 //切换主从时，change master 用到的复制用户
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
2.6 状态检查
# 1、互信检查
[root@db03 ~]# masterha_check_ssh --conf=/etc/mha/app1.cnf
Fri Apr 19 16:39:34 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Fri Apr 19 16:39:34 2019 - [info] Reading application default configuration from /etc/mha/app1.cnf..
Fri Apr 19 16:39:34 2019 - [info] Reading server configuration from /etc/mha/app1.cnf..
Fri Apr 19 16:39:34 2019 - [info] Starting SSH connection tests..
Fri Apr 19 16:39:35 2019 - [debug]
Fri Apr 19 16:39:34 2019 - [debug] Connecting via SSH from [email protected](10.0.0.51:22) to [email protected](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 [email protected](10.0.0.51:22) to [email protected](10.0.0.53:22)..
Fri Apr 19 16:39:35 2019 - [debug] ok.
Fri Apr 19 16:39:36 2019 - [debug]
Fri Apr 19 16:39:35 2019 - [debug] Connecting via SSH from [email protected](10.0.0.52:22) to [email protected](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 [email protected](10.0.0.52:22) to [email protected](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 [email protected](10.0.0.53:22) to [email protected](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 [email protected](10.0.0.53:22) to [email protected](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.
# 2、主从检查
[root@db03 ~]# masterha_check_repl --conf=/etc/mha/app1.cnf
Fri Apr 19 16:40:50 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Fri Apr 19 16:40:50 2019 - [info] Reading application default configuration from /etc/mha/app1.cnf..
Fri Apr 19 16:40:50 2019 - [info] Reading server configuration from /etc/mha/app1.cnf..
Fri Apr 19 16:40:50 2019 - [info] MHA::MasterMonitor version 0.56.
Fri Apr 19 16:40:51 2019 - [info] GTID failover mode = 1
Fri Apr 19 16:40:51 2019 - [info] Dead Servers:
Fri Apr 19 16:40:51 2019 - [info] Alive Servers:
Fri Apr 19 16:40:51 2019 - [info] 10.0.0.51(10.0.0.51:3306)
Fri Apr 19 16:40:51 2019 - [info] 10.0.0.52(10.0.0.52:3306)
Fri Apr 19 16:40:51 2019 - [info] 10.0.0.53(10.0.0.53:3306)
Fri Apr 19 16:40:51 2019 - [info] Alive Slaves:
Fri Apr 19 16:40:51 2019 - [info] 10.0.0.52(10.0.0.52:3306) Version=5.7.20-log (oldest major version between slaves) log-bin:enabled
Fri Apr 19 16:40:51 2019 - [info] GTID ON
Fri Apr 19 16:40:51 2019 - [info] Replicating from 10.0.0.51(10.0.0.51:3306)
Fri Apr 19 16:40:51 2019 - [info] 10.0.0.53(10.0.0.53:3306) Version=5.7.20-log (oldest major version between slaves) log-bin:enabled
Fri Apr 19 16:40:51 2019 - [info] GTID ON
Fri Apr 19 16:40:51 2019 - [info] Replicating from 10.0.0.51(10.0.0.51:3306)
Fri Apr 19 16:40:51 2019 - [info] Current Alive Master: 10.0.0.51(10.0.0.51:3306)
Fri Apr 19 16:40:51 2019 - [info] Checking slave configurations..
Fri Apr 19 16:40:51 2019 - [info] read_only=1 is not set on slave 10.0.0.52(10.0.0.52:3306).
Fri Apr 19 16:40:51 2019 - [info] read_only=1 is not set on slave 10.0.0.53(10.0.0.53:3306).
Fri Apr 19 16:40:51 2019 - [info] Checking replication filtering settings..
Fri Apr 19 16:40:51 2019 - [info] binlog_do_db= , binlog_ignore_db=
Fri Apr 19 16:40:51 2019 - [info] Replication filtering check ok.
Fri Apr 19 16:40:51 2019 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Fri Apr 19 16:40:51 2019 - [info] Checking SSH publickey authentication settings on the current master..
Fri Apr 19 16:40:51 2019 - [info] HealthCheck: SSH to 10.0.0.51 is reachable.
Fri Apr 19 16:40:51 2019 - [info]
10.0.0.51(10.0.0.51:3306) (current master)
+--10.0.0.52(10.0.0.52:3306)
+--10.0.0.53(10.0.0.53:3306)
Fri Apr 19 16:40:51 2019 - [info] Checking replication health on 10.0.0.52..
Fri Apr 19 16:40:51 2019 - [info] ok.
Fri Apr 19 16:40:51 2019 - [info] Checking replication health on 10.0.0.53..
Fri Apr 19 16:40:51 2019 - [info] ok.
Fri Apr 19 16:40:51 2019 - [warning] master_ip_failover_script is not defined.
Fri Apr 19 16:40:51 2019 - [warning] shutdown_script is not defined.
Fri Apr 19 16:40:51 2019 - [info] Got exit code 0 (Not master dead).
MySQL Replication Health is OK.
2.7 db03 启动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 &
# 查看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.8 Manager 参数介绍
# 启动命令参数
nohup //后台管理进程
masterha_manager //MHA启动命令脚本
--conf=/etc/mha/app1.cnf //指定配置文件
--remove_dead_master_conf //从配置文件中，移除宕机的主库信息
--ignore_last_failover //忽略最后一次切换
# MHA配置文件额外参数
# 设置监控主库，发送ping包(mysqldadmin ping)的时间间隔，尝试三次没有回应的时候自动进行failover
ping_interval=1
# 设置为候选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
MHA工作机制：在MHA做完一次切换后，会在工作目录（/etc/mha/app1）中，会生成app1.failover.complete,可以理解是锁文件，8小时之内，不会做第二次切换。
- 传统主从复制与基于MHA的主从复制的区别
传统主从复制
1.主库要开启binlog，从库不用开启binlog
2.主库要有中从复制用户，从库不需要创建主从复制用户
3.主库server_id=5,从库只要不等于5即可，从库之间可以相同
基于MHA的主从复制（从库随时会被提升为新的主库）
1.主库要开启binlog，从库也要开启binlog
2.主库要创建主从复制用户，从库也必须创建主从复制用户
3.主库server_id=5，从库只要不等于5即可，从库之间必须不相同
2.9 MHA切换优先级
- 所有从节点日志都是一致的，默认会以配置文件的顺序去选择一个新主。
- 从节点日志不一致，自动选择最接近于主库的从库
- candidate_master=1
check_repl_delay=0
如果对于某节点设定了权重（candidate_master=1），权重节点会优先选择。
但是此节点日志量落后主库100M日志的话，也不会被选择。可以配合check_repl_delay=0，关闭日志量的检查，强制选择候选节点。
2.10 故障模拟及处理
模拟故障
# 停主库db01:
/etc/init.d/mysqld stop
# 观察manager日志；末尾必须显示如下，才算正常切换成功。
tail -f /var/log/mha/app1/manager
···
Master failover to 10.0.0.52(10.0.0.52:3306) completed successfully.
修复MHA架构
# 修复主库；观察日志，当看到切换主库 successfully 成功，再启动主库。
/etc/init.d/mysqld start
# 修复主从结构
CHANGE MASTER TO
MASTER_HOST='10.0.0.52',
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1,
MASTER_USER='repl',
MASTER_PASSWORD='123';
start slave ;
# 修复配置文件
vim /etc/mha/app1.cnf
[server1]
hostname=10.0.0.51
port=3306
# db03 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 &
3、MHA的vip功能
3.1 准备脚本及配置文件
注意：脚本master_ip_failover必须事先准备好，放在manager节点 /usr/local/bin/下
# 修改脚本配置
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";
# 更改manager配置文件
vi /etc/mha/app1.cnf
添加：
master_ip_failover_script=/usr/local/bin/master_ip_failover
# 转换中文字符格式
yum install -y dos2unix
dos2unix /usr/local/bin/master_ip_failover
# 添加执行权限
[root@db03 ~]# chmod +x /usr/local/bin/master_ip_failover
3.2 手工生成第一个vip地址
- 手工在主库上绑定vip，注意一定要和脚本文件中的ethN一致，我的是eth0:1(1是key指定的值)
ifconfig eth0:1 10.0.0.55/24
3.3 重启mha
masterha_stop --conf=/etc/mha/app1.cnf //关闭
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 //检查状态
故障模拟：
# 停主库db01
/etc/init.d/mysqld stop
# 查看db02 vip 是否漂移；
# 查看管理机日志
tail -f /var/log/mha/app1/manager
···
Sat Feb 8 22:20:56 2020 - [info] Master failover to 10.0.0.52(10.0.0.52:3306) completed successfully.
# 修复db01，登录；重新复制
stop slave;
reset slave all; //清除所有原从库信息
change master to
master_host='10.0.0.51',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;
start slave;
# MHA配置文件将删除的节点补上；如果db02是主库发生故障，则补上db02节点以此类推。
[root@db03 ~]# vim /etc/mha/app1.cnf
[server1]
hostname=10.0.0.51
port=3306
# 启动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
- 生产中主库故障，要确定原主库与新主库数据的一致性，如不一致，需要将原主库数据备份恢复到新主库，原主库变为从库复制新主库。
3.4 调用自动修复节点脚本
[root@db03 ~]# cat recovery_mha.sh
#! /bin/bash
# has down master IP
# old_master= `ssh 10.0.0.53 "sed -nr 's#^Master (.*)\(.*!$#\1#gp' /var/log/mha/app1/manager"`
# replication:change master to ...
change=`ssh 10.0.0.53 "grep -i 'change master to' /var/log/mha/app1/manager"|awk -F: 'END{print $NF}'|sed 's#xxx#123#g'`
# has down master mysqld start
/etc/init.d/mysqld start
# do change master to and start slave;
mysql -e "$change start slave;"
# recover /etc/mha/app1.cnf
ssh 10.0.0.53 '\cp /etc/mha/app1.cnf.ori /etc/mha/app1.cnf' //需要提前将MHA配置文件拷贝一份为 /etc/mha/app1.cnf.ori，作覆盖之用
- 该脚本执行完后需手动启动MHA；
每个节点都存放一个 recovery_mha.sh 脚本，故障节点执行该脚本；
用master_ip_failover脚本添加命令调用此脚本；添加位置如下：
73 sub start_vip() {
74 `ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
75 `ssh $ssh_user\@$orig_master_host \" /bin/sh /root/recovery_mha.sh \"`; //此行为调用命令
76 }
3.5 邮件提醒
1. 参数：
vim /etc/mha/app1.cnf
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 &
3.6 binlog Server
作用：实时保存主库二进制日志的服务，主库有的二进制日志，binlog Server一定有
部署原因：如果主库宕机，从库无法ssh连接主库，从库会缺事务
使用前提：mysql 5.6以上版本，支持gtid并开启，MHA开启
db03配置：
vim /etc/mha/app1.cnf
[binlog1] //定义一个新的标签
no_master=1 //永远不会切换为主库
hostname=10.0.0.53 //有binlog Server 的机器IP
master_binlog_dir=/data/mysql/binlog //日志存放位置，与MHA配置文件里的master_binlog_dir=位置不能一致
# 创建目录
mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/*
# 删除参数
vim /etc/my.cnf
prompt=\\ pc [\\d]> //此参数删除，否则会报错
# 看一下主库的二进制日志
show binary logs;
# 将主库binlog拉过来（从000001开始拉，之后的binlog会自动按顺序过来）
cd /data/mysql/binlog //必须进入到自己创建好的目录
mysqlbinlog -R --host=10.0.0.52 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &
# 注意：拉取日志的起点,需要按照目前从库的已经获取到的二进制日志点为起点
# 重启MHA
masterha_stop --conf=/etc/mha/app1.cnf
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
# binlog Server报错示例
···
Mon Feb 10 18:36:06 2020 - [info] Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/data/mysql/binlog --output_file=/var/tmp/save_binary_logs_test --manager_version=0.56 --start_file=mysql-bin.000033
Mon Feb 10 18:36:06 2020 - [info] Connecting to [email protected](10.0.0.53:22)..
Failed to save binary log: Binlog not found from /data/mysql/binlog! If you got this error at MHA Manager, please set "master_binlog_dir=/path/to/binlog_directory_of_the_master" correctly in the MHA Manager's configuration file and try again.
at /usr/bin/save_binary_logs line 123.
eval {...} called at /usr/bin/save_binary_logs line 70
main::main() called at /usr/bin/save_binary_logs line 66
Mon Feb 10 18:36:06 2020 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln158] Binlog setting check failed!
Mon Feb 10 18:36:06 2020 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln264] Binlog server configuration failed.
Mon Feb 10 18:36:06 2020 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln424] Error happened on checking configurations. at /usr/bin/masterha_check_repl line 48.
Mon Feb 10 18:36:06 2020 - [error][/usr/share/perl5/vendor_perl/MHA/MasterMonitor.pm, ln523] Error happened on monitoring servers.
Mon Feb 10 18:36:06 2020 - [info] Got exit code 1 (Not master dead).
# 报错原因：连接53管理机，在/data/mysql/binlog/目录没有找到binlog文件，对比主库和管理机的/data/mysql/binlog/目录下的binlog文件是否一致。
4、管理员在高可用架构维护的职责
- 搭建：MHA+VIP+SendReport+BinlogServer
- 监控及故障处理
- 高可用架构的优化
核心是：尽可能降低主从的延时，让MHA花在数据补偿上的时间尽量减少。
5.7 版本，开启GTID模式，开启从库SQL并发复制。