深入浅出MHA（MySQL Master High Availability）集群：原理、部署与实践

智能运维探索者

已于 2024-04-18 19:25:11 修改

阅读量7.2k

点赞数 35

文章标签：数据库

于 2024-03-29 16:53:44 首次发布

本文链接：https://blog.csdn.net/hy199707/article/details/137131942

版权

本文聚焦MHA集群，它是MySQL高可用解决方案。介绍了MHA概念、集群原理、同步方式及管理与数据节点职责。详细阐述实现步骤，包括搭建主从复制环境、安装组件、配置ssh免密登录等，还提及故障模拟与恢复，对提升MySQL服务可用性有重要意义。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

引言

在当今高度依赖数据库的应用场景中，MySQL数据库的高可用性显得尤为重要。MHA（MySQL Master High Availability Manager）作为一种开源的MySQL高可用解决方案，以其自动化故障转移和恢复能力广受业界认可。本文将深入探讨MHA集群的原理、部署步骤及实践要点。

一、MHA集群介绍

（一）什么是MHA

MHA（Master High Availability）是一款专为MySQL设计的开源高可用解决方案，主要用于实现MySQL数据库的故障转移和主从复制管理，从而提高数据库服务的可靠性与可用性。MHA由日本人Yoshinori Matsunobu（后来加入Facebook）开发，特别适用于那些需要在主数据库发生故障时迅速切换到备用节点，同时保持数据一致性的场景。

（二）MHA集群原理

MHA由两部分构成：MHA Manager（管理节点）和MHA Node（数据节点）。在主从复制的MySQL集群中，MHA Manager负责监控主节点的健康状况，当主节点出现故障时，MHA Manager会自动选举出一个从节点升级为主节点，并协调其余从节点重新连接至新的主节点，实现无缝的故障转移。

监控与故障检测：MHA Manager通过心跳检测机制实时监控主节点状态，一旦检测到主节点失效，立即触发故障转移流程。

自动故障转移：基于预定义的故障转移策略，如优先级、数据延迟等指标，MHA会选择一个符合条件的从节点晋升为主节点。

数据一致性保证：MHA支持半同步复制和全局事务ID（GTID）复制，以确保故障转移前后数据的一致性。

（三）同步方式

同步复制：主库在接收到写请求后，会等待所有的从服务器同步完毕之后，才会返回给客户端

异步复制：MySQL主从复制默认采用异步复制方式，主库在接收到写请求后立即返回，无需等待从库确认，这种方式响应速度快，但可能存在一定的数据延迟

半同步复制：至少有一个从库接收到并执行完写操作后，主库才返回成功，提高了数据一致性。

（四）管理节点与数据节点

MHA Manager（管理节点）：

MHA Manager是一个中心化的管理组件，通常部署在独立的服务器上，不直接处理数据库的读写请求。

它的主要职责是监控整个MySQL主从集群的健康状态，包括检测主节点是否在线、从节点的复制延迟等。

当主节点出现故障时，MHA Manager会自动执行故障转移流程，选择一个从节点升级为主节点，同时通知其他从节点改变复制源至新的主节点，并确保数据一致性。

MHA Manager还负责处理各种高级特性，比如半同步复制的管理、全局事务标识符（GTID）的支持、以及故障转移过程中的SQL线程暂停和恢复等。

MHA Node（数据节点）：

MHA Node指的是参与MySQL主从复制集群中的所有数据库服务器，包括原来的主节点和从节点。

每个MHA Node都运行着MHA的Node Agent，用于与MHA Manager通信，报告自身状态和接收管理指令。

主节点主要负责处理写入请求和生成二进制日志，而从节点则通过复制主节点的二进制日志来保持数据同步，并在必要时准备晋升为主节点。

二、实现MHA

实现MHA高可用，首先是在实现主从复制的基础之上

环境准备

IP地址	类型	安装软件	安装目录
192.168.83.20	MySQL主服务器	mysql5.7、MHA node 组件	/usr/local/mysql
192.168.83.40	MySQL从服务器1	mysql5.7、MHA node 组件	/usr/local/mysql
192.168.83.60	MySQL从服务器2	mysql5.7、MHA node 组件	/usr/local/mysql
192.168.83.100	MHA节点服务器	MHA node 和 manager 组件	/usr/bin
192.168.83.200	VIP地址

（一）搭建主从复制环境

1.搭建时间同步

在构建MySQL主从复制架构时，确保主从服务器之间的系统时间同步是非常重要的。这是因为MySQL在处理事务和记录二进制日志时依赖于系统时间戳，时间不一致可能会导致主从复制出现问题，如数据不一致或复制中断

##主服务器设置##
yum install ntp -y
#下载ntp服务
 
vim /etc/ntp.conf
--末尾添加--
server 127.127.10.0                            #设置本地是时钟源，注意修改网段
fudge 127.127.10.0 stratum 8                #设置时间层级为8（限制在15内）
 
systemctl start ntpd
#启动服务
 
 
##从服务器设置##
yum install ntp ntpdate -y
 
systemctl start ntpd
#启动服务
 
/usr/sbin/ntpdate 192.168.83.20
#进行时间同步,192.168.83.20为master服务器ip地址
 
crontab -e
*/30 * * * * /usr/sbin/ntpdate 192.168.83.20

2.配置master服务器

2.1 修改配置文件

在/etc/my.cnf文件中添加下图字段，开启二进制日志


server-id = 1
#这个参数是为MySQL服务器分配的一个唯一标识号。在主从复制环境中，无论是主服务器还
#是从服务器,都必须设置一个唯一的server-id。
 
log-bin=master-bin
#log-bin用于开启二进制日志，这是实现MySQL主从复制的关键特性。这里的master-bin是指定
#二进制日志的前缀名称，二进制日志文件将以master-bin.000001,master-bin.000002等格式生成。
 
binlog_format = MIXED
#binlog_format 参数用于设置二进制日志记录格式。可能的值包括 STATEMENT、ROW 和 MIXED。
#MIXED 是一种混合模式，根据实际情况自动在STATEMENT和ROW模式之间切换。
 
log-slave-updates=true
#当设置 log-slave-updates参数为true时,从服务器在执行主服务器传过来的更新时，也会把这些
#更新记录到自己的二进制日志中。这样一来，如果从服务器又被其他从服务器复制，那么这个从服务
#器也可以成为新的主服务器，形成级联复制链。

修改完毕之后重新启动服务：systemctl restart mysqld