1.准备环境 看上节
1.1 配置关键程序软连接
ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /application/mysql/bin/mysql /usr/bin/mysql
1.2 配置各节点互信
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.3 安装软件
下载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
在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
1.4 配置文件准备(db03)
创建配置文件目录
mkdir -p /etc/mha
创建日志目录
mkdir -p /var/log/mha/app1
编辑mha配置文件
cat > /etc/mha/app1.cnf<<EOF
[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
EOF
每台机器都修改一下hosts文件
[root@db01 ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.0.51 db01
[root@db02 ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.0.52 db02
[root@db03 ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.0.53 db03
1.5 状态检测（db03）
[root@db03 ~]# masterha_check_ssh --conf=/etc/mha/app1.cnf
Fri Jun 28 12:23:49 2019 - [debug] ok.
Fri Jun 28 12:23:50 2019 - [info] All SSH connection tests passed successfully. <<看这里
[root@db03 ~]# masterha_check_ssh --conf=/etc/mha/app1.cnf
MySQL Replication Health is OK.
1.6 开启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 &
1.7 查看MHA状态
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:9068) 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. 主从复制架构演变
2.1 基础主从（）
1主1从
1主多从
多级主从
以上架构大部分中小型企业中还在使用，还有一部分用了RDS
============================================================
双主
中型企业，在高可用（谷歌MMM），分布式架构（Mycat，DBLE）
============================================================
环状
多主1从
几乎是没人用
============================================================
2.2 高性能架构-读写分离架构
mysql-proxy --->0.8 停了
360 --->二次开发Atlas
MySQL --->mysql-router
Percona --->ProxySQL
Mariadb ---> Maxscale
2.3 高可用架构
2.3.1 企业高可用性标准（全年无故障率）
99.9%
99.99%
99.999%
99.9999%
2.3.2 高可用架构产品
（1）负载均衡
LVS、F5、Nginx 有一定的高可用能力
（2）主备系统（单活）
KA、HA（roseHA，RHCS）、PowerHA、mc_sg、MHA、MMM 可以保证3个9到4个9
（3）多活系统
PXC（不收费）、MGC（不收费）、InnoDB Cluster（8.0，不收费）、
Oracle RAC（收费）、MySQL Cluster（收费）、Sysbase Cluster、DB2 Cluster
2.4 分布式架构（现在的大趋势）
Mycat 1.65版
DBLE
2.5 NewSQL
RDBMS+NoSQL+分布式
sp
TiDB
巨杉
PolarDB
OceanBase
3. MHA架构模型
3.1 架构图
image.png
image.png
Manager
Node
一主两从（三台机器）
3.2 软件结构
（1）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信息
（2）Node
这些工具通常由MHA Manager的脚本触发，无需人为操作
save_binary_logs 保存和复制master的二进制日志
apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs 清除中继日志（不会阻塞SQL线程）
4. MHA工作过程
4.1 安装过程说明
4.2 软件工作过程（宕机）
4.2.1 manager启动
（1）读取--conf=/etc/mha/app1.cnf
（2）获取到MHA相关的信息（1主2从）
（3）调用masterha_check_ssh脚本,使用ssh_user=root进行互信检查,进行互信检查
（4）调用masterha_check_repl 检查主从复制情况
（5）manager启动成功
（6）通过masterha_master_monitor 以ping_interval=2 为间隔持续健康主句状态
网络，主机，数据库恢复（mha）
（7）当manager监控到master宕机
（8）开始选主过程
算法1：判断是否有《强制主》参数
算法2：判断两个从库谁更新
算法3：按照配置文件的书写顺序（从上往下）
（9）判断主库的SSH的连通性
能：S1和S2立即保存（save_binary_logs）缺失部分的binlog到本地
不能：
在传统模式下：调用apply_diff_relay_logs计算S1和S2的relay-log的差异需要通
[v内容进行复制的对比
在GTID模式下：调用apply_diff_relay_logs计算S1和S2的relay-log的差异只需要对比GTID号码即可，效率较好
最后进行数据补偿
（10）接触S1从库身份
（11）S2和S2构建新的主从关系
（12）移除配置文件中故障节点
（13）manager工作完成，自杀。
额外的功能：
（1）提供Binlog server
（2）应用透明(VIP)
（3）实时通知管理员（send_report）
（4）自愈系统（待开发）
5. 故障模拟及处理
停主库db01
/etc/init.d/mysqld.server stop
image.png
修复主库
（1）启动主库
/etc/init.d/mysqld.server start
（2）恢复主从结构
[root@db03 ~]# grep -i 'change master to ' /var/log/mha/app1/manager
Fri Jun 28 18:17:00 2019 - [info] All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='10.0.0.52', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='xxx';
可以从db03从库中找到'change master to'结构
db01 [(none)]>CHANGE MASTER TO MASTER_HOST='10.0.0.52', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='123';
db01 [(none)]>start slave;
（3）修改配置文件（db03）
[root@db03 ~]# cat /etc/mha/app1.cnf
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog
password=mha
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root
user=mha
[server1]
hostname=10.0.0.51
port=3306
[server2]
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=3306
（4）启动MHA（db03）
[root@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 &
查看状态[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
6. 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
7. MHA的vip功能
参数
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";
更改manager配置文件：
vim /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 eth0:1 down这个命令删除掉
[root@db02 ~]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.52 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 fe80::20c:29ff:fea9:8a04 prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:a9:8a:04 txqueuelen 1000 (Ethernet)
RX packets 17984 bytes 6555546 (6.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8794 bytes 1004168 (980.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.55 netmask 255.255.255.0 broadcast 10.0.0.255
ether 00:0c:29:a9:8a:04 txqueuelen 1000 (Ethernet)
重启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 &
邮件提醒
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.恢复主从环境
看日志文件：
[root@db03 /usr/local/bin]# grep -i 'change master to ' /var/log/mha/app1/manager
Fri Jun 28 20:25:47 2019 - [info] All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='10.0.0.51', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='xxx';
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 &
