Mysql 高可用集群

一、MySQL高可用集群核心概念

1. 高可用定义

MySQL高可用（High Availability，HA）核心是保障数据库服务7×24小时不间断运行，避免因单点故障、硬件损坏、网络故障、软件崩溃等问题导致业务中断，实现故障自动/快速切换、数据不丢失、服务无缝迁移。

2. 核心目标

• 故障自愈：主节点故障后，快速选举新主节点，业务无需手动干预

• 数据一致性：集群内节点数据同步，避免数据丢失或错乱

• 负载均衡：分散读写压力，提升数据库整体并发处理能力

• 易运维：支持节点动态扩缩容，便捷监控与故障修复

3. 高可用衡量指标

• RTO（恢复时间目标）：故障发生到服务恢复的时间，越短越好

• RPO（恢复点目标）：故障后允许丢失的数据量，理想状态为0

• 可用性百分比：如99.9%（年 downtime 8.76小时）、99.99%（年 downtime 52.56分钟）、99.999%（年 downtime 5.26分钟）

二、主流MySQL高可用集群架构对比

生产环境中MySQL高可用方案主要分为传统主从HA架构、官方组复制架构、分布式集群架构三大类，适配不同业务规模与场景：

架构方案 核心原理 优点 缺点 适用场景

MHA（Master High Availability） 基于主从复制，管理器监控主库，故障时自动切换从库为新主 部署简单、兼容传统主从、切换速度快（秒级）、成本低 无数据强一致性、需额外部署管理器、不支持多主写入、需手动配置VIP 中小型企业、传统主从升级高可用、读多写少业务

MGR（MySQL Group Replication） MySQL官方组复制，基于Paxos协议，多节点副本同步，强一致性，自动选主 官方原生、数据强一致性、自动故障切换、支持单主/多主模式、无第三方依赖 对网络要求高、性能略低于主从、集群节点数建议3-5个、大事务易影响同步 中大型企业、金融/电商等对数据一致性要求高的核心业务

MMM（Master-Master Replication Manager） 双主复制+虚拟IP，监控节点状态，故障切换VIP 架构简单、双主互备、读写分离便捷 数据一致性差、易出现脑裂、维护成本高、官方不再推荐 早期老旧项目、非核心业务

MySQL InnoDB Cluster 基于MGR+MySQL Router+MySQL Shell，一体化集群方案 全套官方工具、可视化管理、自动路由、高安全性、易部署 依赖官方生态、硬件资源要求较高、大并发场景需优化 云原生场景、企业级核心业务、快速搭建高可用集群

Percona XtraDB Cluster/PXC 基于Galera协议，多主同步复制，强一致性，无主从概念 多主同时写入、无单点故障、数据实时同步、扩容简单 性能损耗较大、不支持MyISAM引擎、网络延迟敏感 高并发写入、多地域部署、核心数据业务

重点推荐架构

1. 中小型业务：MHA，低成本、易维护，兼容现有主从架构

2. 中大型核心业务：MGR/InnoDB Cluster，官方原生、强一致、高可靠

3. 高并发多写场景：PXC，多主写入，无同步延迟

三、MGR（MySQL组复制）高可用集群实操

1. MGR核心原理

基于Paxos分布式一致性协议，集群内节点通过消息传递达成数据一致，分为单主模式（默认，自动选主，仅主节点可写）和多主模式（所有节点均可读写，适合高并发写入），节点数推荐奇数个（3/5），避免脑裂，半数以上节点存活集群即可正常运行。

2. 前置要求

• MySQL 5.7.17+ 或 8.0+，所有节点版本一致

• 节点之间网络互通，关闭防火墙/SELinux，时钟同步

• 仅支持InnoDB引擎，必须有主键，开启binlog

• 节点配置独立server-id，相同的group_replication_group_name

3. 核心配置（my.cnf，3节点集群示例）

ini

mysqld

基础配置

server-id=1 # 三个节点分别设为1、2、3

datadir=/var/lib/mysql

socket=/var/lib/mysql/mysql.sock

log-error=/var/log/mysqld.log

pid-file=/var/run/mysqld/mysqld.pid

character-set-server=utf8mb4

default-storage-engine=InnoDB

binlog配置（MGR必须开启）

log_bin=mysql-bin

binlog_format=ROW

binlog_checksum=NONE

log_slave_updates=ON

expire_logs_days=7

MGR核心配置

plugin-load-add=group_replication.so

transaction_write_set_extraction=XXHASH64

group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" # 集群唯一UUID

group_replication_start_on_boot=OFF

group_replication_local_address="节点IP:33061" # 节点内部通信端口

group_replication_group_seeds="节点1IP:33061,节点2IP:33061,节点3IP:33061"

group_replication_bootstrap_group=OFF

group_replication_single_primary_mode=ON # 单主模式

group_replication_enforce_update_everywhere_checks=OFF

4. 集群搭建步骤

5. 所有节点安装MySQL，加载MGR插件，创建复制用户

sql

SET SQL_LOG_BIN=0;

CREATE USER repl@'%' IDENTIFIED BY 'Repl@123';

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@'%';

FLUSH PRIVILEGES;

SET SQL_LOG_BIN=1;

2. 首个节点启动集群（引导节点）

sql

SET GLOBAL group_replication_bootstrap_group=ON;

START GROUP_REPLICATION;

SET GLOBAL group_replication_bootstrap_group=OFF;

3. 其他节点加入集群

sql

START GROUP_REPLICATION;

4. 查看集群状态

sql

SELECT * FROM performance_schema.replication_group_members;

显示所有节点状态为ONLINE即为集群搭建成功。

5. 故障切换机制

单主模式下，主节点故障后，集群自动选举新主节点（基于节点权重、server-id排序），无需人工干预，配合MySQL Router可实现应用无感知切换。

四、MHA高可用集群实操

1. MGR架构组成

• Manager节点：1台，监控主库状态，执行故障切换

• Master节点：1台，负责写操作

• Slave节点：2台及以上，负责读操作，同步主库数据

• VIP（虚拟IP）：绑定主库，故障时漂移到新主库

2. 核心优势

• 基于传统MySQL主从复制，无需修改数据库内核

• 切换速度快（通常3-30秒），支持binlog补偿，减少数据丢失

• 支持主从复制延时监控，自动处理复制异常

3. 搭建核心步骤

4. 所有节点配置SSH免密登录，安装MHA Manager和Node包

5. 配置主从复制，确保主从数据同步

6. 编辑MHA配置文件，指定主从节点、VIP、切换脚本

7. 启动MHA监控，测试主库故障，验证自动切换效果

五、MySQL InnoDB Cluster一体化集群

1. 架构组件

• MySQL Server：基于MGR的数据库节点

• MySQL Router：轻量代理，实现读写分离、故障路由、负载均衡

• MySQL Shell：命令行管理工具，用于集群创建、节点管理、状态监控

2. 核心优势

• 一站式部署，无需手动配置MGR，可视化操作

• 自动处理故障切换，Router自动转发请求，应用无需修改连接地址

• 支持集群扩容、节点重启、状态检查，运维成本极低

3. 简易搭建命令（MySQL Shell）

sql

连接Shell，创建集群

shell.connect('root@节点1IP:3306')

var cluster = dba.createCluster('mysql_cluster')

添加从节点

cluster.addInstance('root@节点2IP:3306')

cluster.addInstance('root@节点3IP:3306')

查看集群状态

cluster.status()

六、高可用集群关键问题与解决方案

1. 脑裂问题

原因：集群网络分裂，多个节点同时认为自己是主节点，导致数据错乱

解决方案：

• 集群节点数设为奇数（3/5），基于Paxos/Raft协议选举，半数以上节点同意才生效

• 配置网络心跳检测，开启隔离故障节点机制

• MGR自带脑裂防护，无需额外配置

2. 数据一致性问题

原因：主从异步复制延迟，故障切换导致数据丢失

解决方案：

• 核心业务采用MGR强一致性模式，同步复制确保数据一致

• 开启半同步复制（Semisync Replication），主库等待从库确认接收binlog再提交

• 定期使用pt-table-checksum工具校验主从数据，及时修复不一致

3. 故障切换后应用无感知

解决方案：

• 搭配VIP/Keepalived，实现IP漂移

• 使用MySQL Router/MyCat/ProxySQL中间件，应用连接中间件，中间件自动转发到健康节点

• 避免应用直接连接数据库节点IP

4. 集群性能优化

• MGR集群避免大事务、长事务，拆分批量操作，减少同步阻塞

• 集群节点同机房部署，降低网络延迟

• 主库专注写操作，读请求全部分发到从节点

• 合理设置连接池，避免大量连接耗尽数据库资源

七、生产环境高可用集群最佳实践

1. 架构选型：核心业务优先MGR/InnoDB Cluster，非核心业务用MHA，避免使用MMM

2. 节点部署：集群节点跨服务器/机架部署，避免硬件单点故障，节点数3个即可满足高可用

3. 监控告警：部署Prometheus+Grafana监控集群状态、节点存活、复制延迟、RTO/RPO指标，配置短信/邮件告警

4. 数据备份：集群≠备份，定期执行全量+增量备份，异地存储，定期测试恢复流程

5. 权限管理：集群专用用户仅授予最小权限，禁止超级用户随意操作

6. 版本统一：集群内所有节点MySQL版本、配置、硬件配置保持一致

7. 故障演练：定期模拟主库故障、网络中断场景，验证集群切换能力，优化切换流程

八、集群运维常用命令

MGR常用命令

sql

启动/停止MGR

START GROUP_REPLICATION;

STOP GROUP_REPLICATION;

查看集群成员

SELECT * FROM performance_schema.replication_group_members;

查看集群状态

SELECT * FROM performance_schema.replication_group_member_stats;

切换多主模式

SET GLOBAL group_replication_single_primary_mode=OFF;

SET GLOBAL group_replication_enforce_update_everywhere_checks=ON;

InnoDB Cluster常用命令

sql

查看集群状态

cluster.status()

重启集群

cluster.reboot()

移除故障节点

cluster.removeInstance('root@故障节点IP:3306')

创建Router路由

dba.deployRouter('mysql_router', cluster)