2019-06-28 Day12~MHA高可用
2019-06-29 本文已影响0人
Ffvc
上节回顾：
主从复制
1.介绍
二进制日志作用：实现主从复制
2.主从复制搭建前提
两台机器
二进制日志
server_id
复制用户
数据预同步
change master to
start slave
3.名词
文件：
主库：binlog
从库：relay-log，master.info，relay-log.info
线程：
主库：binlog_dump_thread
从库：IO SQL
4.主从工作原理
image.png
5.主从复制故障分析
show slave status \G
IO 线程报错场景
connecting：连接不上
网络
防火墙
IP
port
user
password
手工连接测试
No：
binlog server_id
SLQ 线程
从库写入
进行从库的只读或者读写分离，物理隔离
6. 主从延时
主库：DUMP线程，串行投递日志
GTID + 双一
从库：SQL线程回放，串行
MTS
7.延时从库
主要解决：逻辑损坏问题
对SQL线程进行配置
应用：
- 监控到
- 停止主库当前业务，从库SQL线程关闭
- 人工模拟SQL线程干活
- 找到relay-log 的起点和终点并截取日志
- 从库恢复
- 将从库替换为主库，对外提供服务
（1）stop slave；
（2）reset slave all； - 补偿原主库数据和现在的新主库数据保持一致，并且重新构建主从
=====================================
过滤复制
1.恢复昨天主从复制状态
image.png
image.png
image.png
image.png
MAH环境部署
一、MAH环境搭建
1.1、创建软链接
注意：三个节点都做
ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /application/mysql/bin/mysql /usr/bin/mysql
1.2、配置各节点互信
注意：以下操作一条命令一条命令复制
db01操作：
[root@db01 ~]# rm -rf /root/.ssh
[root@db01 ~]# ssh-keygen
[root@db01 ~]# cd /root/.ssh
[root@db01 ~]# mv id_rsa.pub authorized_keys
[root@db01 ~]# scp -r /root/.ssh 10.0.0.52:/root
[root@db01 ~]# scp -r /root/.ssh 10.0.0.53:/root
各节点验证
db01:
[root@db01 ~]# ssh 10.0.0.51 date
[root@db01 ~]# ssh 10.0.0.52 date
[root@db01 ~]# ssh 10.0.0.53 date
db02:
[root@db02 ~]# ssh 10.0.0.51 date
[root@db02 ~]# ssh 10.0.0.52 date
[root@db02 ~]# ssh 10.0.0.53 date
db03:
[root@db03 ~]# ssh 10.0.0.51 date
[root@db03 ~]# ssh 10.0.0.52 date
[root@db03 ~]# ssh 10.0.0.53 date
1.3、安装软件
所有节点安装Node软件依赖包
yum install perl-DBD-MySQL -y
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
在db01主库中创建mha需要的用户
[root@db01 ~]# mysql -uroot -p
db01 [(none)]> grant all privileges on *.* to mha@'10.0.0.%' identified by 'mha';
Manager软件安装（db03）
[root@db03 ~]# yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
[root@db03 ~]# rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm
1.4 、配置文件准备(db03)
创建配置文件目录
[root@db03 ~]# mkdir -p /etc/mha
创建日志目录
[root@db03 ~]# mkdir -p /var/log/mha/app1
编辑mha配置文件
[root@db03 ~]# 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] #节点1
hostname=10.0.0.51
port=3306
[server2] #节点2
hostname=10.0.0.52
port=3306
[server3] #节点3
hostname=10.0.0.53
port=3306
EOF
1.5、状态检查(db03)
[root@db03 ~]# masterha_check_ssh --conf=/etc/mha/app1.cnf #检查秘钥
[root@db03 ~]# masterha_check_repl --conf=/etc/mha/app1.cnf #检查一主两从
1.6、开启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 &
注释：
--ignore_last_failover #跳过最后一次故障检查
1.6、查看MHA状态
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
[root@mysql-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@mysql-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@mysql-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.1、基础主从（不依赖于其他的任何软件）
1主1从
1主多从
多级主从
----------------------->以上架构大部分中小型企业中还在用，还有一部分用了RDS
双主
----------------------->中型企业（MMM），在高可用，分布式架构（Nycat，DBLE）
环状3
多主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）主备系统（单活）
KA HA(roseHA,RHCS)，PowerHA，mc_sg，MHA，MMM，可以保证3个9到4个9标准
（3）多活系统
PXC（不收费），MGC（不收费），MySQL Cluster（收费），InnoDB Cluster（8.0，不收费）
Oracle RAC（收费），Sysbase Cluster（收费），DB2 Cluster（收费）
2.4、分布式架构（现在的大趋势）
Mycat 1.65
DBLE
2.5、NewSQL
RDBMS+NoSQL+分布式
sp
TiDB
巨杉
polarDB
OceanBase
MHA 架构模型
三、MHA 架构模型
3.1、架构图
image.png
3.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信息
Node工具包主要包括以下几个工具：
这些工具通常由MHA Manager的脚本触发，无需人为操作
save_binary_logs 保存和复制master的二进制日志
apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs 清除中继日志（不会阻塞SQL线程）
MHA 工作流程
四、MHA工作过程
4.1、安装过程说明
上面以已经有步骤
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_relay_logs计算S1和S2的 relay-log差异
需要通过内容进行复杂的对比
在GTID模式下：调用apply_diff_relay_logs计算S1和S2的 relay-lig差异
只需要对比GTID号码即可，效率较高
最后进行数据补偿
（10）接触S1从库身份
（11）S2和S1构建新的主从关系
（12）移除配置文件中故障节点
（13）manager工作完成，自杀（一次性的高可用）
额外的功能:
（1）提供了Binlog Server
（2）应用透明（VIP）
（3）实时通知管理员（send_report）
（4）自愈系统（待开发）
故障模拟及处理
五、故障模拟
1、故障模拟
前提，确保MHA是启动的，才能做一下操作
[root@db01 ~]# systemctl stop mysqld.service
image.png
2、修复故障
#1、启动db01
[root@db01 ~]# systemctl start mysqld
#2、查看日志
[root@db03 ~]# grep -i 'change master to ' /var/log/mha/app1/manager
Fri Jun 28 18:22:16 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';
#3、恢复主从结构
[root@db01 ~]# mysql -uroot -p
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;
#4、修改配置文件 (db03操作)
[root@db03 ~]# vim /etc/mha/app1.cnf
[server1]
hostname=10.0.0.51
port=3306
#5、启动MHA
[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 &
#6、查看MHA状态
[root@db03 ~]# masterha_check_repl --conf=/etc/mha/app1.cnf
MySQL Replication Health is OK.
3、MHA高可用修复成功截图
image.png
Manager 额外参数介绍
六、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功能
七、MHA 的vip功能
使用到的参数
master_ip_failover_script=/usr/local/bin/master_ip_failover
注意：/usr/local/bin/master_ip_failover，必须事先准备好
1、使用per的脚本
[root@db03 ~]# 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 = '10.0.0.55/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig eth1:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth1:$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";
}
2、修改脚本内容（只需要修改这几行）
[root@db03 ~]# vim /usr/local/bin/master_ip_failover
my $vip = '10.0.0.55/24'; #用于vip的IP
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip"; #看实际要求修改主机名
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down"; #看实际要求修改主机名
3、将上述脚本内容的DOS格式文本文件转换成UNIX格式，并将脚本文件重新授权
[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
4、更改manager配置文件：
[root@db03 ~]# vim /etc/mha/app1.cnf
添加：
master_ip_failover_script=/usr/local/bin/master_ip_failover
5、在主库上手工绑定vip
#查看主库在那个节点上
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:17245) is running(0:PING_OK), master:10.0.0.52
#主库上手工配置vip地址
[root@db02 ~]# ifconfig eth0:1 10.0.0.55/24
注意：
手工在主库上绑定vip，注意一定要和配置文件中的ethN一致，我的是eth0:1(1是key指定的值)
6、重启MHA
[root@db03 ~]# masterha_stop --conf=/etc/mha/app1.cnf
[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 &
MHA部署邮件提醒功能
八、邮件提醒功能部署
1. 使用到的参数
report_script=/usr/local/bin/send
2. 上传邮件脚本
(1)准备发邮件的脚本(上传到db03的/usr/local/bin/中)
#修改脚本里面的邮箱地址，改成自己的邮箱
[root@db03 ~]# vim /usr/local/bin/testpl
增加执行权限
[root@db03 ~]# chown +x /usr/local/bin/*
3. 修改manager配置文件，调用邮件脚本
[root@db03 ~]# vim /etc/mha/app1.cnf
report_script=/usr/local/bin/send
image.png
4.停止MHA，开启MHA
[root@db03 ~]# masterha_stop --conf=/etc/mha/app1.cnf
[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 &
5.关闭主库,看警告邮件，并修复主从
故障修复：
1. 恢复故障节点
#启动宕机实例
[root@db02 ~]# systemctl start mysqld
注意：
主机损坏，有可能数据也损坏了
备份并恢复故障节点。
2.恢复主从环境
#查看日志
[root@db03 ~]# grep -i 'change master to ' /var/log/mha/app1/manager
Fri Jun 28 18:22:16 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';
3、恢复主从结构
[root@db02 ~]# mysql -uroot -p
db02 [(none)]> CHANGE MASTER TO
MASTER_HOST='10.0.0.52',
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1,
MASTER_USER='repl',
MASTER_PASSWORD='123';
db02 [(none)]> start slave;
4.恢复manager
#修好的故障节点配置信息，加入到配置文件
[root@db02 ~]# vim /etc/mha/app1.cnf
[server1]
hostname=10.0.0.52
port=3306
5.启动manager
[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 &
恢复完成之后效果图
image.png
