第 24 章：组复制

这是《MySQL 8.0 源码与内核实战》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 Group Replication 用分布式一致性协议维护成员视图和事务认证，提供多主或单主高可用方案。它建立在 Binlog 和 GTID 之上。

24.1 架构

MySQL Server
  -> binlog
     -> group replication plugin
        -> certification
           -> group communication
              -> apply local transaction

组件：

1. local capture；
2. certification；
3. applier；
4. recovery；
5. group communication system；
6. membership。

24.2 单主与多主

生产更常用 single-primary，配合代理和探活实现自动切换。

24.3 事务流程

local trx commit
  -> broadcast to group
     -> certify conflict
        |-- conflict: rollback
        +-- no conflict:
           -> consensus order
              -> write relay
                 -> apply
                    -> ack

认证依赖 GTID 和 write set。binlog_transaction_dependency_tracking 与 transaction_write_set_extraction 等配置会影响冲突检测能力。

24.4 冲突

多主下两个节点同时修改同一行可能冲突：

trx A certified first
trx B same row
  -> B rollback

减少冲突：

1. 按业务分片写入节点；
2. 主键设计稳定；
3. 避免跨分片热点；
4. 缩短事务；
5. 应用重试确定性错误；
6. 优先单主模式。

24.5 Flow Control

组复制包含流控，避免快节点长期等待慢节点：

队列积压时限制事务进入组，表现为写入延迟上升。

24.6 Recovery

新成员或落后成员加入时：

joiner
  -> select donor
     -> clone or incremental recovery
        -> catch up
           -> online

大量落后时优先使用 Clone Plugin 重建；小差距可用增量恢复。

24.7 观测

SELECT * FROM performance_schema.replication_group_members;
SELECT * FROM performance_schema.replication_group_member_stats;
SELECT * FROM performance_schema.replication_connection_status;

重点看成员状态、队列长度、冲突事务、认证延迟和事务吞吐。

24.8 生产要点

1. 网络延迟直接影响提交；
2. 三节点或更多奇数成员；
3. 单主模式减少冲突；
4. 代理必须识别主角色；
5. 大事务会造成队列积压；
6. 表必须有主键；
7. 与 MGR 不兼容的特性需提前评审；
8. 切换演练不可省略。

本章小结

组复制通过成员协议、事务认证和恢复机制构建高可用集群。单主模式更易治理，核心风险是网络延迟、队列积压、写冲突和大事务。

思考题

1. MGR 与传统异步复制的提交差异是什么？
2. 多主冲突如何检测和处理？
3. flow control 为什么会造成写入延迟？
4. 新成员加入有哪些恢复方式？
5. 为什么 MGR 要求表有主键？