解锁MySQL高可用新境界：深入探索MHA架构的无限魅力与实战部署

•  作者简介：我是团团儿，是一名专注于云计算领域的专业创作者，感谢大家的关注
•  座右铭：   云端筑梦，数据为翼，探索无限可能，引领云计算新纪元
•  个人主页：团儿.-CSDN博客

目录

前言：

正文：

MHA高可用  ****

1.MHA 架构软件结构说明

MHA Manager‌：

‌MHA Node‌：

2.节点规划

2.1MHA软件的构成(perl语言)

Manager工具包主要包括以下几个工具：

Node工具包主要包括以下几个工具：

3. MHA 配置过程细节说明

3.1 修改配置文件

主库db01：

slave1(db02)：

slave2(db03)：

3.2 启动数据库

3.3 构建主从：

db01:

db02\db03:

3.4 互信

db01：

各节点验证（三台均验证）

3.5 安装软件包(所有节点)

3.6 在db01主库中创建mha需要的用户

3.7  Manager软件安装（db03）

3.8 配置文件准备(db03)

-- 创建配置文件目录

-- 创建日志目录

-- 编辑mha配置文件

3.9 状态检查(db03)

4. MHA FailOver过程详解

4.1 什么是Failover?

4.2 Failover让你实现怎么做?

4.3 MHA的Failover如何实现?

5. MHA 应用透明(vip)

db03:

修改配置文件：

安装插件：

修改格式：

赋予权限：

 修改：

添加至第二行:

db01:手工添加vip

6. MHA 故障提醒

添加邮件脚本：

测试：

修改：

写入脚本：

测试：

7. 额外的数据补偿(binlog_server)

(1)找一台额外的机器，必须要有5.6以上的版本，支持gtid并开启，我们直接用的第二个slave

（db03）

(2) 拉取主库binlog日志

(4) 重启MHA-manager 

8. 故障模拟及故障处理

8.1 宕掉 db01 数据库

在db03上查看日志：

8.2 恢复故障

(1) 启动故障节点

(2) 恢复1主2从(db01)

(3) 恢复配置文件(db03)

(4) 启动MHA 

(5)恢复binlogserver 

前言：

在当今的数据驱动时代，数据库的稳定性和高可用性是企业业务连续性的基石。MySQL，作为最流行的开源关系型数据库管理系统之一，广泛应用于各种规模的企业和项目中。然而，随着业务量的不断增长和数据重要性的日益凸显，MySQL单点故障的问题逐渐显现，成为制约系统稳定性和可靠性的关键因素。

为了应对这一挑战，业界提出了多种高可用性和故障转移的解决方案，其中MHA（Master High Availability）以其高效、灵活和自动化的特点脱颖而出。MHA是由日本的一位MySQL专家采用Perl语言编写的一套脚本管理工具，专为MySQL Replication环境设计，旨在维持Master主库的高可用性。

MHA的核心优势在于其自动的master故障转移和Slave提升功能。当Master节点出现故障时，MHA能够迅速识别并自动将具有最新数据的Slave提升为新的Master，同时确保所有其他Slave重新指向新的Master，整个过程对应用程序几乎透明，从而最大限度地减少服务中断和数据丢失的风险。

此外，MHA还支持多种高级特性，如binlog server、半同步复制等，这些特性不仅提高了数据传送的效率，还进一步增强了数据的一致性和安全性。通过MHA，企业可以构建出更加健壮、可靠的MySQL高可用架构，为业务的持续稳定运行提供有力保障。

本文将深入探讨MHA的架构、工作原理、安装配置以及在实际应用中的最佳实践。通过本文的学习，您将能够全面了解MHA在MySQL高可用环境中的重要作用，并掌握如何利用MHA来构建和维护一个高效、稳定的数据库系统。

正文：

MHA高可用  ****

1.MHA 架构软件结构说明

MHA Manager‌：

负责监控和管理MySQL主从复制集群。它可以单独部署在一台独立的机器上，管理多个master-slave集群，也可以部署在一台slave节点上。MHA Manager会定时探测集群中的master节点，当master出现故障时，MHA Manager能够自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

‌MHA Node‌：

运行在每台MySQL服务器上，负责数据的复制和同步。MHA Node是数据节点，它参与主从复制过程，确保数据的一致性和可用性。

MHA的设计目标是解决MySQL的高可用性问题，特别是在主服务器宕机的情况下，能够迅速将最新的数据从一个slave服务器提升为新的master，从而最大程度地减少服务中断的时间。此外，MHA还支持半同步复制，以降低数据丢失的风险，并保证所有节点的数据一致性。MHA主要支持一主多从的架构，要求至少三台服务器：一台作为master，其余作为slave。这种架构对应用程序透明，意味着在故障转移过程中，应用程序无需进行任何配置更改即可继续无缝运行‌。

2.节点规划

manager端: db03
node端: db01,db02,db03
1主2从,独立数据库实例

2.1MHA软件的构成(perl语言)

Manager工具包主要包括以下几个工具：

mha4mysql-manager-0.58-0.el7.centos.noarch.rpm

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工具包主要包括以下几个工具：

rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm
这些工具通常由MHA Manager的脚本触发，无需人为操作
save_binary_logs            保存和复制master的二进制日志 
apply_diff_relay_logs       识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs            清除中继日志（不会阻塞SQL线程）

3. MHA 配置过程细节说明

3.1 修改配置文件

主库db01：

cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/usr/local/mysql/
datadir=/usr/local/mysql/data
socket=/tmp/mysql.sock
server_id=1
port=3306
secure-file-priv=/tmp
autocommit=1
log_bin=mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db01>
EOF

slave1(db02)：

cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
socket=/tmp/mysql.sock
server_id=2
port=3306
secure-file-priv=/tmp
autocommit=1
log_bin=mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db02>
EOF

slave2(db03)：

cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
socket=/tmp/mysql.sock
server_id=3
port=3306
secure-file-priv=/tmp
autocommit=1
log_bin=mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db03>
EOF

3.2 启动数据库

systemctl restart mysqld

3.3 构建主从：

master:db01
slave:db02,db03

db01:

grant replication slave  on *.* to repl@'192.168.8.%' identified by '123';

db02\db03:

change master to 
master_host='192.168.8.9',
master_user='repl',
master_port=3306,
master_password='123' ,
MASTER_AUTO_POSITION=1;
start slave;

3.4 互信

db01：

ssh-keygen
cd /root/.ssh 
mv id_rsa.pub authorized_keys

scp  -r  /root/.ssh  192.168.8.10:/root 
scp  -r  /root/.ssh  192.168.8.11:/root 

各节点验证（三台均验证）

ssh 192.168.8.9 hostname
ssh 192.168.8.10 hostname
ssh 192.168.8.11 hostname

3.5 安装软件包(所有节点)

通过网盘分享的文件：mha-node.zip
链接: node包提取码: 3mkq

3.6 在db01主库中创建mha需要的用户

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

3.7  Manager软件安装（db03）

通过网盘分享的文件：mha-manager.zip
链接: manager包 提取码: agqk

3.8 配置文件准备(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=/usr/local/mysql/data       
user=mha                                   
password=mha                               
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root                               
[server1]                                   
hostname=192.168.8.9
port=3306                                  
[server2]            
hostname=192.168.8.10
port=3306
[server3]
hostname=192.168.8.11
port=3306
EOF

3.9 状态检查(db03)

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

4. MHA FailOver过程详解

4.1 什么是Failover?

故障转移.
主库宕机一直到业务恢复正常的处理过程(自动)

4.2 Failover让你实现怎么做?

(1) 快速监控到主库宕机
(2) 选择新主
(3) 数据补偿
(4) 解除从库身份
(5) 剩余从库和新主库构建主从关系
(6) 应用透明
(7) 故障节点自愈(待开发...) 
(8) 故障提醒

4.3 MHA的Failover如何实现?

从启动--->故障--->转移--->业务恢复
(1) MHA通过masterha_manger脚本启动MHA的功能.
(2) 在manager启动之前,会自动检查ssh互信(masterha_check_ssh)和主从状态(masterha_check_repl)
(3) MHA-manager 通过 masterha_master_monitor脚本(每隔ping_interval秒)
(4) masterha_master_monitor探测主库3次无心跳之后,就认为主库宕机了.
(5) 进行选主过程 ***
    算法一: 
    读取配置文件中是否有强制选主的参数?
    candidate_master=1
    check_repl_delay=0
    扩展一下:
    candidate_master=1 应用场景?
        (a) MHA+KeepAlive VIP(早期MHA架构)
        (b) 多地多中心
    算法二:
    自动判断所有从库的日志量.将最接近主库数据的从库作为新主.
    算法三:
    按照配置文件先后顺序的进行选新主.
    

(6) 数据补偿 
判断主库SSH的连通性
情况一: SSH能连
调用 save_binary_logs脚本,立即保存缺失部分的binlog到各个从节点,恢复
情况二: SSH无法连接
调用 apply_diff_relay_logs 脚本,计算从库的relaylog的差异,恢复到2号从库
(6.1) 提供额外的数据补偿的功能@@
(7) 解除从库身份
(8) 剩余从库和新主库构建主从关系
(9) 应用透明  @@
(10) 故障节点自愈(待开发...)@@
(11) 故障提醒@@

5. MHA 应用透明(vip)

db03:

通过网盘分享的文件：master_ip_failover.txt
链接: 文件 提取码: 1qas

mv master_ip_failover.txt /usr/local/bin/
cd /usr/local/bin/
mv master_ip_failover.txt master_ip_failover

修改配置文件：

vim /usr/local/bin/master_ip_failover

安装插件：

yum install -y  dos2unix

修改格式：

dos2unix /usr/local/bin/master_ip_failover

赋予权限：

chmod +x /usr/local/bin/master_ip_failover

 修改：

vim /etc/mha/app1.cnf 

添加至第二行:

master_ip_failover_script=/usr/local/bin/master_ip_failover

db01:手工添加vip

6. MHA 故障提醒

systemctl stop postfix
systemctl disable postfix

添加邮件脚本：

vim /etc/mail.rc 

set from=1119898630@qq.com
set smtp=smtps://smtp.qq.com:465
set smtp-auth-user=1119898630@qq.com
set smtp-auth-password=eufnwvekwqnlhdch
set smtp-auth=login
set ssl-verify=ignore
set nss-config-dir=/etc/pki/nssdb/

测试：

echo 111 | mail -s test 1119898630@qq.com

修改：

vim /etc/mha/app1.cnf

添加第三行：

report_script=/usr/local/bin/send

保存退出

写入脚本：

cat >> /usr/local/bin/send << EOF
#!/bin/bash
echo "mha is failover,hehe" | mail -s mha_alert 1119898630@qq.com
EOF

chmod +x /usr/local/bin/send

测试：

7. 额外的数据补偿(binlog_server)

(1)
找一台额外的机器，必须要有5.6以上的版本，支持gtid并开启，我们直接用的第二个slave

（db03）

mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/mysql

vim /etc/mha/binlogserver.cnf 

添加：

[binlog1]
no_master=1
hostname=192.168.8.11
master_binlog_dir=/data/mysql/binlog/

(2) 拉取主库binlog日志

cd /data/mysql/binlog    
mysqlbinlog  -R --host=192.168.8.9 --user=mha --password=mha --raw  --stop-never mysql-bin.000001 &

注意：
拉取日志的起点,需要按照目前主库正在使用的binlog为起点.

(4) 重启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

8. 故障模拟及故障处理

8.1 宕掉 db01 数据库

systemctl stop mysqld 

在db03上查看日志：

tailf /var/log/mha/app1/manager
grep "CHANGE MASTER TO"  /var/log/mha/app1/manager

第二台查看漂移地址
第三台查看主从

8.2 恢复故障

(1) 启动故障节点

systemctl start mysqld

(2) 恢复1主2从(db01)

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

(3) 恢复配置文件(db03)

vim /etc/mha/app1.cnf

将8.9重新添加至配置文件：

[server1]
hostname=192.168.8.9
port=3306
[server2]
hostname=192.168.8.10
port=3306
[server3]
hostname=192.168.8.11
port=3306

(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)恢复binlogserver 

cd /data/mysql/binlog  
mv mysql-bin.*  /tmp
mysqlbinlog  -R --host=192.168.8.10 --user=mha --password=mha --raw  --stop-never mysql-bin.000001 &

期待您的关注~