Mysql高可用之MHA

几种高可用方案介绍

高可用架构

单活 :
keeplived+ 双主+1从(MMM)

MHA(三节点 1主两从)

TMHA(1主1从)

多活:

NDB(收费)

InnoDB Cluster

PXC(percona XtraDB Cluster)

MGC(MariaDB glaera Cluster)

高性能架构

读写分离架构

Atlas(360)

Cobar

ProxySql (Percona)

Mysql Router

分布式架构

Atlas-Sharding(360)

Mycat(DBLE)

TDDL(淘宝)

MHA原理

主库宕机处理过程

监控节点 (通过配置文件获取所有节点信息)

系统,网络,SSH连接性

主从状态,重点是主库

选主
- 如果判断从库(position或者GTID),数据有差异,最接近于Master的slave,成为备选主
- ```
如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主.
```
- 如果设定有权重(candidate_master=1),按照权重强制指定备选主.
  - 默认情况下如果一个slave落后master 100M的relay logs的话，即使有权重,也会失效.
  - 如果check_repl_delay=0的化,即使落后很多日志,也强制选择其为备选主
数据补偿
- 当SSH能连接,从库对比主库GTID 或者position号,立即将二进制日志保存至各个从节点并且应用(save_binary_logs )
- 当SSH不能连接, 对比从库之间的relaylog的差异(apply_diff_relay_logs)
Failover 将备选主进行身份切换,对外提供服务其余从库和新主库确认新的主从关系
应用透明(VIP)
故障切换通知(send_reprt)
二次数据补偿(binlog_server)
自愈自治(待开发…)

架构介绍

1主2从

Manager软件随便选一个主机或者装在某个节点上

Node软件所有的节点都需要安装

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官网：mha官网

github下载地址：github

安装node软件依赖所有节点

yum install perl-DBD-MySQL -y
rpm -ivh mha4mysql-node-0.58-0.el7.noarch.rpm

安装manager软件依赖只在manager节点

yum install -y epel-release
yum install -y perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
rpm -ivh mha4mysql-manager-0.58-0.el7.noarch.rpm

在主库中创建MHA需要的用户

grant all privileges on *.* to mha@'192.168.57.%' identified by 'mha';

Manager节点配置文件

创建配置文件目录

mkdir -p /etc/mha

创建日志目录

mkdir -p /var/log/mha/app1
mkdir /data/binlog

编辑mha配置文件

vim /etc/mha/app1.cnf
[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=192.168.57.3
port=3306                                  
[server2]            
hostname=192.168.57.4
port=3306
[server3]
hostname=192.168.57.5
port=3306

状态检查

互信检查

前提三台机器都做了ssh互信
masterha_check_ssh  --conf=/etc/mha/app1.cnf 
成功状态如下
All SSH connection tests passed successfully.

验证主从状态

检查这一步前确保所有的数据库都配置了log-bin 否则验证不通过

masterha_check_repe  --conf=/etc/mha/app1.cnf 
返回状态如下
MySQL Replication Health is OK.

开启MHA 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 &

查看状态

masterha_check_status --conf=/etc/mha/app1.cnf
返回状态如下
app1 (pid:26871) is running(0:PING_OK), master:192.168.57.3

Manager额外参数介绍

说明：
主库宕机谁来接管？

所有从节点日志都是一致的，默认会以配置文件的顺序去选择一个新主。
从节点日志不一致，自动选择最接近于主库的从库
如果对于某节点设定了权重（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

故障模拟主库宕机修复

停止主库查看日志，发现主库已经漂移到了192.168.57.4

[root@node3 ~]# tail -f /var/log/mha/app1/manager
Master 192.168.57.3(192.168.57.3:3306) is down!

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

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

重新启动192.168.57.3数据库服务器并修复主从

注意这里地址要指向主库192.168.57.4

CHANGE MASTER TO 
MASTER_HOST='192.168.57.4',
MASTER_PORT=3306, 
MASTER_AUTO_POSITION=1, 
MASTER_USER='repl', 
MASTER_PASSWORD='123';

START SLAVE;

修复MHA配置文件，加入如下内容

[server1]
hostname=192.168.57.3
port=3306

重新启动MHA

[root@node3 ~]# 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] 7403
[root@node3 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:7403) is running(0:PING_OK), master:192.168.57.4

MHA的VIP功能

配置文件中新增如下内容

[root@node3 ~]# cat /etc/mha/app1.cnf  
[server default]  
master_ip_failover_script=/usr/local/bin/master_ip_failover

脚本下载地址

master_ip_failover.zip

重启MHA

前提是在主库上首次需要配置VIp地址

比如ifconfig eth0:1 192.168.1.10/24 ，相关地址根据自己实际情况修改

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 &

邮件提醒功能

配置文件增加以下内容

[root@node3 ~]# cat /etc/mha/app1.cnf 
[server default]
report_script=/usr/local/bin/send_report

MHA binlog Server

配置文件增加以下内容

cat /etc/mha/app1.cnf 
[binlog1]
no_master=1
hostname=192.168.57.5
master_binlog_dir=/tmp/binlog

创建binlog目录

mkdir /tmp/binlog
[root@node3 ~]# chown -R mysql:mysql /tmp/binlog/

拉取主库目前所在的binlog位置

[root@node3 ~]# cd /tmp/binlog/
 mysqlbinlog -R --host=192.168.57.3 --user=mha --password=mha --raw --stop-never mysql-bin.000006 &

重启MHA

[root@node3 binlog]# 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 &
[2] 21309
[root@node3 binlog]# masterha_check_status --conf=/etc/mha/app1.cnf 
app1 (pid:21309) is running(0:PING_OK), master:192.168.57.3

故障处理

主库宕机，binlogserver 自动停掉，manager 也会自动停止。
处理思路：

1、重新获取新主库的binlog到binlogserver中

2、重新配置文件binlog server信息

3、最后再启动MHA

Mysql

#Linux

Mysql高可用之MHA

http://www.jcwit.com/article/31/

作者

Carlos

发布于

2019年6月14日

许可协议

Mysql 优化上一篇

Mysql主从进阶下一篇