MySQL5.7高可用MHA

MySQL高可用MHA

一、架构工作原理

主库宕机处理过程
1. 监控节点 (通过配置文件获取所有节点信息)
   系统,网络,SSH连接性
   主从状态,重点是主库

2.选主
 2.1.优先级(主观)，如果在节点配置时，加入了candidate_ master= 1参数。
	如果备选主，日志量落后master太多 (后master 100M的relay logs的话，)也不会被选择新主。可以通过check repl delay=0， 不检查日志落后的情景。
 2.2.日志量最接近主库
 2.3.日志量一样。配置文件顺序。
3.日志补偿
	#情况1: ssh能连上，通过save binary logs立即保存缺失部分的日志到从库(/var/tmp目录下)并恢复。
	#情况2: ssh不能连，两个从库进行relaylog日志diff(apply diff relay logs)差异补偿。
4.主从身份切换，所有从库取消和原有主库的复制关系(stop slave; reset slave all)新主库和剩余从库  重新构建主从关系。
5.故障库自动被剔除集群(masterha conf host配置信息去掉)
6. MHA是一次性的高可用，Failover后， Manager自动推出。

二、架构介绍

1主2从，master：master   slave：slave1   slave2 ）：
MHA 高可用方案软件构成
Manager软件：选择一个从节点安装
Node软件：所有节点都要安装

# 架构不足的地方
0.应用透明
1.数据补偿
2.自动提醒
3.自愈功能待开发....
	MHA + k8s + Operator官方
	8.0 MGR + mysqlsh

三、 MHA软件构成

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线程）

四、MHA环境搭建

4.1、环境规划

主库: 
192.168.1.111      Node软件 
从库: 
192.168.1.112      Node软件
192.168.1.113      Node软件    Manager软件（生产建议把Manager软件独立放另一台服务器上）

4.2、准备环境（略。1主2从GTID）

看另外的笔记吧，简单明了

4.3、配置各节点互信（免密登录）

master：
rm -rf /root/.ssh 
ssh-keygen
cd /root/.ssh 
mv id_rsa.pub authorized_keys
scp  -r  /root/.ssh  192.168.1.112:/root 
scp  -r  /root/.ssh  192.168.1.113:/root 

4.4、配置关键程序软连接(三台机器上都是)

ln -s /data/mysql/bin/mysqlbinlog    /usr/bin/mysqlbinlog
ln -s /data/mysql/bin/mysql          /usr/bin/mysql

4.5、 安装mha、Node

mha官网：https://code.google.com/archive/p/mysql-master-ha/
github下载地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads

4.5.1、所有节点安装Node软件依赖包

# 下载好mha4mysql-node-0.56-0.el6.noarch.rpm，上传到三台机器的/app目录下，执行以下命令
[root@slave1 app]# yum install perl-DBD-MySQL -y
[root@slave1 app]# rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm

4.6、在主库新建用户

grant all privileges on *.* to mha@'192.168.1.%' identified by 'mha';
grant all privileges on *.* to mha@'%' identified by 'mha';
#两个从库检查
mysql -p123 -e "select user,host from mysql.user;"

4.7、软件安装（在从库192.168.1.113 上）

# 把下载好的软件mha4mysql-manager-0.56-0.el6.noarch.rpm上传到slave2的/app目录下，执行以下命令
[root@slave2 app]# yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
[root@slave2 app]# rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm

4.7.1、 Manager配置文件（在从库192.168.1.113 上）

# 创建配置文件目录、创建日志目录
[root@slave2 app]# mkdir -p /etc/mha
[root@slave2 app]# mkdir -p /var/log/mha/app1
# 编辑mha配置文件
cat > /etc/mha/app1.cnf << EFO
[server default]
manager_log=/var/log/mha/app1/manager        
manager_workdir=/var/log/mha/app1            
master_binlog_dir=/data/mysql  #主节点日志文件目录  
user=mha           #mha工作过程中专用的用户，刚刚上面新建的                         
password=mha       #mha工作过程中专用的用户，刚刚上面新建的                             
ping_interval=2    #监控间隔时间，2秒一次
repl_password=123  #主从复制的密码
repl_user=tzh      #主从复制的用户
ssh_user=root                               
[server1]                                   
hostname=192.168.1.111
port=3306                                  
[server2]            
hostname=192.168.1.112
port=3306
[server3]
hostname=192.168.1.113
port=3306
EFO

4.8、状态检查（在从库192.168.1.113 上）

# 互信检查
[root@slave2 app]# masterha_check_ssh  --conf=/etc/mha/app1.cnf 
# 看到如下日志表示成功
Sun Nov 22 04:10:12 2020 - [info] All SSH connection tests passed successfully.

# 主从状态检查
[root@slave2 app]# masterha_check_repl  --conf=/etc/mha/app1.cnf 
# 看到如下日志表示成功
MySQL Replication Health is OK.

4.9、开启MHA（在从库192.168.1.113 上）

[root@slave2 app]# 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 &

4.10、查看MHA状态

[root@slave2 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:19660) is running(0:PING_OK), master:192.168.1.111
[root@slave2 ~]# mysql -umha -pmha -h 192.168.1.111 -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@slave2 ~]# mysql -umha -pmha -h 192.168.1.112 -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@slave2 ~]# mysql -umha -pmha -h 192.168.1.113 -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    |
+---------------+-------+

4.11、故障模拟及处理

### 停主库master    
[root@master app]# systemctl stop mysqld

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

Master 192.168.1.111(192.168.1.111:3306) is down!

Check MHA Manager logs at slave2:/var/log/mha/app1/manager for details.

Started automated(non-interactive) failover.
Selected 192.168.1.112(192.168.1.112:3306) as a new master.
192.168.1.112(192.168.1.112:3306): OK: Applying all logs succeeded.
192.168.1.113(192.168.1.113:3306): OK: Slave started, replicating from 192.168.1.112(192.168.1.112:3306)
192.168.1.112(192.168.1.112:3306): Resetting slave info succeeded.
Master failover to 192.168.1.112(192.168.1.112:3306) completed successfully.

4.12、故障恢复

A、修复主库

[root@master app]# systemctl start mysqld

B、恢复主从结构

CHANGE MASTER TO 
MASTER_HOST='192.168.1.112',  #现在112是主库了
MASTER_PORT=3306, 
MASTER_AUTO_POSITION=1, 
MASTER_USER='tzh', 
MASTER_PASSWORD='123';
start slave ;

C、修改配置文件

[root@slave2 ~]# vim /etc/mha/app1.cnf 加上这段（当你打开会惊喜的发现没有了这段哦）
[server1]
hostname=192.168.1.111
port=3306

D、启动MHA

[root@slave2 ~]# 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 &

五、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

六、MHA 的vip功能

6.1、添加参数（Manager上，slave3）

注意：/usr/local/bin/master_ip_failover，必须事先准备好  #自带vip只能在同机房实现
[root@slave2 ~]# vim /etc/mha/app1.cnf
# 加在[server default]标签下即可
master_ip_failover_script=/usr/local/bin/master_ip_failover

6.1.2、脚本

[root@slave2 ~]# vim /usr/local/bin/master_ip_failover
#!/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 = '192.168.1.254/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig ens33:$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 "

IN SCRIPT TEST====$ssh_stop_vip==$ssh_start_vip===

";

    if ( $command eq "stop" || $command eq "stopssh" ) {

        my $exit_code = 1;
        eval {
            print "Disabling the VIP on old master: $orig_master_host 
";
            &stop_vip();
            $exit_code = 0;
        };
        if ($@) {
            warn "Got Error: $@
";
            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 
";
            &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 
";
        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
";
}

# 给权限
[root@slave2 ~]# chmod +x /usr/local/bin/master_ip_failover

# 主库手工加VIP
# 手工在主库上绑定vip，注意一定要和配置文件中的ethN一致，我的是ens33:1(1是key指定的值)
[root@master ~]# yum install net-tools -y   #三台机器都得安装
[root@master ~]# ifconfig ens33:1 192.168.1.254/24
[root@master ~]# ifconfig ens33:1 down  

6.2、邮件提醒

#没做

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) 关闭主库,看警告邮件 

6.3、重启mha

[root@master ~]# masterha_stop --conf=/etc/mha/app1.cnf
[root@master ~]# 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 &

七、binlog server（slave2上）

binlogserver配置：
找一台额外的机器，必须要有5.6以上的版本，支持gtid并开启，我们直接用的第二个slave（db03）
vim /etc/mha/app1.cnf 
    
# 在最后加上就行
[binlog1]   
no_master=1   						  #主库宕机、切换的时候不切到这里了
hostname=192.168.1.113				  #本机ip
master_binlog_dir=/data/mysql/binlog  #日志目录
    
# 创建目录
# 修改完成后，将主库binlog拉过来（从000001开始拉，之后的binlog会自动按顺序过来）
[root@slave2 ~]# mkdir -p /data/mysql/binlog
[root@slave2 ~]# chown mysql.mysql -R /data/mysql/binlog

#拉取主库binlog日志
[root@slave2 ~]# cd /data/mysql/binlog     ----->必须进入到自己创建好的目录
#host是主库的IP,不做这个会报错哦
[root@slave2 binlog]# mysqlbinlog  -R --host=192.168.1.111 --user=mha --password=mha --raw  --stop-never mysql-bin.000001 &
注意：
	#到主库show master status;看看在使用那个binlog文件，从这个开始啦就行！
	拉取日志的起点,需要按照目前从库的已经获取到的二进制日志点为起点
	mysqlbinlog  -R --host=192.168.1.111 --user=mha --password=mha --raw  --stop-never mysql-bin.000xxx &

# 查看
[root@slave2 binlog]# ll
total 16
-rw-r----- 1 root root  177 Nov 22 00:05 mysql-bin.000001
-rw-r----- 1 root root 3435 Nov 22 00:05 mysql-bin.000002
-rw-r----- 1 root root  379 Nov 22 00:05 mysql-bin.000003
-rw-r----- 1 root root  359 Nov 22 00:05 mysql-bin.000004

八、再次测试，把主库停机

# 关闭主库
[root@master ~]#  systemctl stop mysqld

# 观察slave2上的日志情况
[root@slave2 ~]# tail -f /var/log/mha/app1/manager

主库宕机，binlogserver 自动停掉，manager 也会自动停止。
处理思路：
1、重新获取新主库的binlog到binlogserver中
2、重新配置文件binlog server信息
3、最后再启动MHA


故障修复：
1. 恢复故障节点
（1）实例宕掉
/etc/init.d/mysqld start 
（2）主机损坏，有可能数据也损坏了
备份并恢复故障节点。
2.恢复主从环境
看日志文件：恢复新主库的日志
CHANGE MASTER TO MASTER_HOST='192.168.1.112', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='tzh', MASTER_PASSWORD='123';
start slave ;
3.恢复manager
3.1 修好的故障节点配置信息，加入到配置文件
[server1]
hostname=10.0.0.51
port=3306
3.2 查看VIP是否在master，不在就手动加
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 &