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=OFF3. 部署步骤
- 初始化集群（引导节点）
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）