day12(高可用）
2019-06-29 本文已影响0人
五月_w
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 &
