【MySQL】第12节|MySQL 8.0 主从复制原理分析与实战(二)
一、组复制(MGR)核心概念
1. 定义与定位
- 目标:解决传统主从复制的单点故障、数据不一致问题,提供高可用、高扩展的分布式数据库方案。
- 基于 GTID:依赖全局事务标识符(GTID)实现事务一致性,确保跨节点事务唯一且有序。
- 分布式协议:基于 Paxos 协议实现节点间数据共识,保证事务在多数节点提交后才生效。
2. 核心优势
传统主从复制 | 组复制(MGR) |
单主节点,存在单点故障 | 多节点集群,支持单主或多主模式 |
异步复制,可能丢数据 | 半同步或强一致性(取决于配置) |
手动故障转移 | 自动选主(单主模式) |
从节点只读 | 多主模式下节点可读写 |
3. 应用场景
- 高可用性集群:金融、电商等不能容忍单点故障的场景。
- 多活数据中心:支持多主写入,适合跨地域数据同步。
- 读写高并发:多主模式下分摊写压力(需解决冲突)。
二、组复制模式与原理
1. 单主模式(推荐)
- 特点:
- 集群中仅有一个主节点(Primary)接受写请求,其余节点为从节点(Secondary,只读)。
- 主节点故障时,自动选举新主节点(基于 Paxos 协议)。
- 适用场景:大多数业务场景,避免多主写入冲突。
2. 多主模式
- 特点:
- 所有节点均可读写,适合分布式事务或跨地域写入。
- 需启用 冲突检测(如
group_replication_enforce_update_everywhere_checks=ON
),避免主键冲突。
- 风险:写入冲突可能导致事务回滚,需谨慎设计业务逻辑。
3. 核心组件
- Group Replication 插件:实现节点间通信、事务认证和复制。
- GTID 集合:记录已执行的事务,确保节点数据一致。
- 分布式恢复机制:新节点加入时,通过全量备份+增量 GTID 同步数据。
三、单主模式部署步骤(基于 Docker)
1. 环境规划
节点角色 | server_id | 端口 | 配置文件 |
mgr-node1(主) | 1 | 3321 | custom.cnf(主节点配置) |
mgr-node2(从) | 2 | 3322 | custom.cnf(从节点配置) |
mgr-node3(从) | 3 | 3323 | custom.cnf(从节点配置) |
2. 关键配置文件(custom.cnf
)
[mysqld]
# 基础配置
server_id=1 # 唯一节点ID
gtid_mode=ON # 启用GTID
enforce_gtid_consistency=ON # 强制GTID一致性
log-bin=mysql-bin # 二进制日志
default-time_zone='+8:00' # 时区# 组复制配置
plugin_load_add='group_replication.so' # 加载组复制插件
group_replication_group_name="117dc7ea-b9bd-11ee-9bdb-0242ac120002" # 统一组名(UUID格式)
group_replication_local_address="mgr-node1:33061" # 内部通信地址(端口自定义)
group_replication_group_seeds="mgr-node1:33061,mgr-node2:33061,mgr-node3:33061" # 种子节点列表
group_replication_bootstrap_group=OFF # 非引导节点设为OFF
3. 创建复制用户
-- 在所有节点执行
CREATE USER 'fox'@'%' IDENTIFIED BY '123456';
GRANT REPLICATION SLAVE, GROUP_REPLICATION_STREAM ON *.* TO 'fox'@'%';
FLUSH PRIVILEGES;
4. 启动组复制
- 引导主节点(mgr-node1):
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;
- 加入从节点(mgr-node2/mgr-node3):
START GROUP_REPLICATION;
5. 验证集群状态
-- 查看组成员
SELECT MEMBER_HOST, MEMBER_ROLE, MEMBER_STATE FROM performance_schema.replication_group_members;-- 查看主节点
SHOW STATUS LIKE 'group_replication_primary_member';
四、多主模式关键调整
- 关闭单主模式:
SET GLOBAL group_replication_single_primary_mode=OFF;
- 启用冲突检测:
SET GLOBAL group_replication_enforce_update_everywhere_checks=ON;
- 注意事项:
- 避免跨节点更新同一数据(如共享主键表)。
- 使用中间件(如 MySQL Router)路由读写请求。
五、与传统主从复制的对比
维度 | 传统主从复制 | 组复制(MGR) |
复制协议 | 异步/半同步 | 基于 Paxos 的共识协议 |
故障转移 | 手动或依赖外部工具(如 MHA) | 自动选举(单主模式) |
数据一致性 | 最终一致(异步) | 强一致(多节点确认) |
写扩展性 | 单主写入 | 多主写入(需处理冲突) |
部署复杂度 | 较低 | 较高(需配置插件和分布式协议) |
六、注意事项与最佳实践
- 节点数量:建议奇数节点(如 3/5 个),确保多数派共识(
N ≥ 2f+1
,f 为允许故障节点数)。 - 网络要求:低延迟、高可靠网络,避免脑裂(Split-Brain)。
- 监控告警:
- 跟踪
Seconds_Behind_Master
(单主模式)或冲突日志。 - 使用 Prometheus + MySQL Exporter 监控集群状态。
- 跟踪
- 备份与恢复:
- 新节点加入需全量备份(如
mysqldump
)+ GTID 增量同步。 - 避免在复制中直接删除数据文件,可能导致 GTID 空洞。
- 新节点加入需全量备份(如
七、总结
组复制(MGR)是 MySQL 官方提供的高可用解决方案,通过 GTID 和分布式协议解决了传统复制的痛点。单主模式适合大多数场景,而多主模式需谨慎评估业务冲突风险。实际应用中,建议结合中间件(如 MySQL Router)和监控工具,构建健壮的分布式数据库集群。