1、上节回顾

1、介绍

2、主从复制的前提
      2台机器
      二进制日志
      server_id不同
      创建复制用户
      数据预同步
      change master to
      start slave

3、名词介绍
      文件：
              主库：binlog   二进制日志
              从库：master.info   主库信息
                         relay_ log   中继日志
                         relay_log.info  中继日志应用                    

       线程：
               主库：binlog_dump_thread

               从库：IQ  SQL


4、主从复制的原理


5、主从复制故障分析
show slave status\G

IO:
      connecting:
               网络、防火墙、IP、port、user、password

       no:
            binlog     server_id
SQL：
        从库写入
         进行从库的只读或者读写分离物理隔离
       

6、主从延时
      主库：DUMP线程 串行投递日志
       GTID+双一
       从库： SQL线程回放  串行
       MTS


7、延时从库
      主要解决逻辑损坏
      对SQL线程进行配置

应用：
        1、监控到
        2、停止主库业务，关闭从库SQL
        3、人工模拟SQL干活
        4、截取relay的起点和终点
        5、恢复从库
        6、将从库替换成主库，对外提供服务
        7、补偿原主库数据和新主库保持一致，并重新构建主从

2、主从复制架构演变

2.1、基础主从（不依赖与其他的任何软件）

1主1从
1主多从
多级主从
---------------------->以上架构大部分中小型企业还在用，还有一部分用了RDS
双主
---------------------->中型企业，在高可用（MMM），分布式架构（Mycat   ,   DBLE）
环状
多主1从
------------------------>几乎没人用 

2.2、高性能架构 ---读写分离架构

mysql-proxy   ------->   0.8   停了
360   ------->二次开发  Atlas    Atlas-sharding   2016年
MySQL   ------->mysql-router
Percona   ------->ProxySQL
Mariadb   ------->Maxscale

2.3、高可用架构

2.3.1、企业高可用性标准（去年无故障率）

99%                 (1-99%)x365=3.65dx24≈ 87.60小时
99.9%               (1-99.9%)x365=0.365dx24≈ 8.760小时             ---> 互联网级别
99.99%              (1-99.99%)x365=0.0365dx24≈ 0.8760小时        ---> 准金融级别
99.999%             (1-99.999%)x365=0.00365dx24≈ 0.08760小时     ---> 金融级别  
99.9999%            (1-99.9999%)x365=0.000365dx24≈ 0.008760小时  ---> “0” 宕机

2.3.2、高可用架构产品

  (1)  负载均衡
         LVS   F5   nginx  有一定的高可用能力
  (2)  主备系统（单活）

（3）多活系统
          PXC(不收费），MGC（不收费），MySQL Cluster（收费），Innodb Cluster(8.0 不收费） Oracle RAC(收费）

2.4、分布式架构(现在的大趋势）

Mycat  1.65
DBLE

2.5、NewSQL

RDBMS+NoSQL+分布式
sp
TiDB
巨杉
polarDB
OceanBase

3、MHA 架构模型

3.1、架构图

image.png

Manager
Node
一主两从（三台独立主机）

3.2、软件结构

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线

4、MHA 工作过程

4.1、安装过程说明

1) 配置关键程序软连接（主从都做）
ln -s /application/mysql/bin/mysqlbinlog    /usr/bin/mysqlbinlog
ln -s /application/mysql/bin/mysql          /usr/bin/mysql

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


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


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


 5）状态检查(db03)

masterha_check_ssh  --conf=/etc/mha/app1.cnf 
masterha_check_repl  --conf=/etc/mha/app1.cnf



 .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 &


7）查看MHA状态
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf

4.2、软件工作过程（宕机的时候）

4.2.1、manager 启动

（1）读取--conf=/etc/mha/app1.cnf配置文件
（2）获取到node相关信息（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）开始选主过程
         算法一：判断是否有《强制主》参数
         算法二：判断两个从库谁更新
         算法三：按照配置文件书写顺序
（9）判断主库SSH的连通性
         能 ：s1  和  s2  立即保存（save_binary_logs）缺失部分的binlog到本地
         不能：
            在传统模式下，调用apply_diff_logs计算s1和s2的relay_log的差异
            需要通过内容进行复杂的对比
            在GTID模式下：调用apply_diff_logs计算s1和s2的relay_log的差异 
            只需要对比GTID号码即可，效率较高
          最后进行数据补偿
（10）解除s1从库身份
（11）s2和s1构建新的主从关系
（12）移除配置文件中故障节点
（13）manager工作完成，自杀。（一次性的高可用）


额外的功能：
（1）提供Binlog Server
（2）应用透明（VIP）
（3）实时通知管理员（send_report）
（4）自愈（待开发。。。。。）

5、故障模拟及处理

5.1、停主库db01:

systemctl stop mysqld

观察manager  日志 tail -f /var/log/mha/app1/manager
末尾必须显示successfully，才算正常切换成功。   

5.2、修复故障库：

systemctl start mysqld

5.3、恢复主从结构

[root@db03 ~]# grep -i 'change master to ' /var/log/mha/app1/manager

db01:
CHANGE MASTER TO 
MASTER_HOST='10.0.0.52',
MASTER_PORT=3306, 
MASTER_AUTO_POSITION=1, 
MASTER_USER='repl', 
MASTER_PASSWORD='123';
start slave ;

5.4、修改配置文件(db03)

vim /etc/mha/app1.cnf
[server1]
hostname=10.0.0.51
port=3306

5.5、启动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 &


检查状态
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功能(db03)

参数:
master_ip_failover_script=/usr/local/bin/master_ip_failover

注意：/usr/local/bin/master_ip_failover，必须事先准备好

修改脚本内容
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

注意：
[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


重启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 &

8、邮件提醒

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 &