MySQL高可用集群笔记

一、核心概念

1. 高可用指标

RTO (Recovery Time Objective) ：故障恢复时间，核心业务要求 <30s
RPO (Recovery Point Objective) ：数据丢失量，核心业务要求 RPO=0
脑裂：网络分区导致多主同时写入，数据不一致
多数派：集群节点数 >N/2 确认，才能提交事务（防脑裂）

2. 主流方案对比

表格

方案	核心原理	一致性	切换	优缺点	适用场景
主从 + Keepalived	binlog 异步 / 半同步 + VIP	弱 / 半强	手动 / 脚本	简单、成本低；切换慢、易丢数据	非核心、中小业务
MHA	主从 + 自动选主	半强	秒级	切换快；停更、SSH 依赖、单点	传统主从升级
MGR (组复制)	Paxos 共识、原生集群	强一致 (RPO=0)	自动秒级	官方、自愈、多主；仅 InnoDB、大事务敏感	金融、核心交易
PXC/Galera	同步多主、Galera 协议	强一致	自动	多写、无单点；仅 InnoDB、性能低	多活、高并发读

二、主从复制（基础高可用）

1. 核心原理

主库：写操作 → 记录 binlog
从库：IO 线程拉 binlog → 中继日志 → SQL 线程回放
模式：异步（默认）、半同步（至少 1 从 ACK 才提交）、增强半同步

2. 关键配置（my.cnf）

主库 (server-id=1)

ini

复制代码

server-id=1
log-bin=mysql-bin
binlog_format=ROW          # 行模式（一致性好）
gtid_mode=ON               # 全局事务ID（切换必备）
enforce_gtid_consistency=ON
binlog_rows_query_log_events=ON
sync_binlog=1
innodb_flush_log_at_trx_commit=1  # 双1（安全）

# 半同步
plugin-load-add=rpl_semi_sync_master.so
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_wait_point=AFTER_SYNC
rpl_semi_sync_master_timeout=1000  # 1s降级异步

从库 (server-id=2)

ini

复制代码

server-id=2
read_only=1
super_read_only=1          # 8.0+ 超级只读
relay-log=relay-bin
log_slave_updates=1
gtid_mode=ON
enforce_gtid_consistency=ON

# 并行复制 (5.7+)
slave_parallel_type=LOGICAL_CLOCK
slave_parallel_workers=8   # CPU核数

3. 部署步骤

主库创建复制用户

sql

复制代码

CREATE USER 'repl'@'%' IDENTIFIED BY 'Repl@123';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

主库备份（mysqldump --single-transaction --master-data=2）
从库恢复备份，启动复制

sql

复制代码

CHANGE MASTER TO
  MASTER_HOST='192.168.1.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='Repl@123',
  MASTER_AUTO_POSITION=1;  # GTID自动定位
START SLAVE;

4. 高可用增强

Keepalived：绑定 VIP，主挂则漂移到从
监控：MHA/Orchestrator 自动切换

三、MGR 集群（官方首选）

1. 核心特性

单主模式（推荐）：1 主可写，多从只读，自动选主
多主模式：所有节点可写，冲突检测（主键 / 写集）
Paxos 共识：事务需多数派（>N/2）确认
自动故障转移：30s 内完成，RPO=0
节点数：3/5/7（奇数，防脑裂），最大 9 节点

2. 核心配置（3 节点）

ini

复制代码

# 通用
server-id=101/102/103
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_format=ROW
log_slave_updates=ON
plugin-load-add=group_replication.so

# MGR专属
group_replication_start_on_boot=OFF
group_replication_bootstrap_group=OFF
group_replication_group_name="uuid"          # 集群UUID
group_replication_local_address="ip:33061"   # 组通信端口
group_replication_group_seeds="ip1:33061,ip2:33061,ip3:33061"
group_replication_ip_whitelist="192.168.1.0/24"
group_replication_single_primary_mode=ON     # 单主
group_replication_enforce_update_everywhere_checks=OFF

3. 部署步骤

初始化集群（引导节点）

sql

复制代码

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

其他节点加入

sql

复制代码

START GROUP_REPLICATION;

查看状态

sql

复制代码

SELECT * FROM performance_schema.replication_group_members;

4. 故障切换流程

心跳超时 → 标记主节点 UNREACHABLE
多数派投票 → 按 GTID 进度 + 权重 选新主
新主关闭 super_read_only
原主恢复 → 自动加入为从

四、MHA 方案（经典）

1. 架构

Manager：独立节点，监控、选主、切换
Node：每台 MySQL，执行日志补全、切换
依赖：SSH 免密 、GTID

2. 核心优势

切换快（<30s）、数据补偿、支持多从
兼容所有存储引擎

3. 局限

2018 年后停更、Manager 单点、SSH 安全风险

五、生产最佳实践

1. 方案选型

中小业务 / 非核心：主从 + Keepalived
核心 / 金融 ：MGR 单主（3 节点）
多写 / 多活：PXC 或 MGR 多主（谨慎）

2. 关键配置

强一致：MGR、半同步、双 1（sync_binlog=1、innodb_flush_log_at_trx_commit=1）
防脑裂：奇数节点、多数派、网络冗余
性能：并行复制、大内存、SSD、分库分表

3. 监控与运维

监控：MGR 状态、复制延迟、节点存活、VIP
工具：Prometheus+Grafana、Orchestrator、MHA
备份：每日全备 + 实时 binlog 备份

4. 故障处理

MGR 单主：自动切换，无需人工
主从：MHA 自动切换，或手动提升从库
脑裂：切断网络 、修复后重新加入集群

六、常见问题

MGR 大事务延迟 → 拆分事务、控制单事务大小
主从延迟 → 并行复制、ROW 模式、优化从库
脑裂 → 网络稳定、奇数节点、关闭自动重连
数据不一致 → 强一致方案、定期校验（pt-table-checksum）