MySQL 主从复制并不是只有一种“主库写、从库读”的实现方式。根据对数据一致性和性能的不同侧重，复制可以配置为三种截然不同的模式：异步复制、半同步复制和组复制。理解它们之间的本质区别，是在架构设计时做出正确取舍的前提。
19.2.1 异步复制（Asynchronous Replication）
异步复制是 MySQL 最原始、也是最经典的复制模式。它的工作流程极其简单：
- 主库执行事务，写入 Binlog。
- 主库的 Binlog Dump 线程将 Binlog 事件发送给从库的 I/O 线程。
- 主库不等待从库的任何确认，直接向客户端返回事务提交成功。
- 从库异步地拉取、中继、回放这些事件。
在这种模式下，主库和从库之间不存在任何同步屏障，主库的性能几乎不受影响。缺点是如果主库在事务提交后、Binlog 被从库拉取前发生崩溃，这些已经提交的事务就会丢失（从库上没有这些数据）。这种丢失的风险取决于网络延迟和主库故障的时机，在金融、支付等强一致性要求的场景下不可接受。
实用要点：
- MySQL 默认复制模式即为异步。不需要额外安装插件，配置简单。
- 适合场景：读多写少、对数据一致性要求不太苛刻的业务，或从库仅用于备份、数据分析等允许一定延迟和少量数据丢失的场景。
- 性能影响：几乎可忽略。主库的事务提交速度不受从库状况影响。
19.2.2 半同步复制（Semi-Synchronous Replication）
半同步复制是为了弥补异步复制可能丢数据的缺陷而设计的。它的核心思路是：主库提交事务时，必须至少有一个从库确认已接收到该事务的 Binlog 后，主库才向客户端返回成功。
工作流程：
- 主库将事务写入 Binlog，等待从库确认。
- 从库 I/O 线程收到 Binlog 后，写入自己的中继日志（Relay Log），并向主库发送 ACK。
- 主库收到 ACK 后，向客户端返回提交成功。
如果等待超，主库会临时退化为异步复制，直到从库恢复后再恢复半同步。这样即使主库崩溃，由于至少有一个从库已经拿到了 Binlog，这些事务不会丢失。
半同步复制又有两个关键参数，决定确认时机：
- AFTER_SYNC（MySQL 5.7 后默认）：主库将事务写入 Binlog 并刷盘，等待从库返回 ACK，之后再提交引擎层（写 Redo Log）。这是推荐的方式，因为主库在提交引擎日志前已经确保了 Binlog 被从库接收，即使崩溃，引擎层的修改尚未提交，事务整体可以视为未完成，数据一致性更强。
- AFTER_COMMIT：主库先完成引擎提交，再等待从库的 ACK。优点是主库恢复时因 Redo 和 Binlog 已经一致，但崩溃后可能已经向客户端返回提交成功的部分事务在从库尚未接收，存在少量丢失可能。较少使用。
配置方式（以 MySQL 8.0 为例）：
- 主库安装插件：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; - 从库安装插件：
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; - 主库设置：
SET GLOBAL rpl_semi_sync_master_enabled = 1; - 从库设置：
SET GLOBAL rpl_semi_sync_slave_enabled = 1; - 需要重启从库 I/O 线程：
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
实用要点：
- 半同步复制只保证“至少一个从库”收到 Binlog，其他从库可能仍未接收。因此发生主库切换时要选择那个已确认的从库作为新主库。
- 性能影响：每事务多一次网络往返，会增加提交延迟（通常是几十微秒到几毫秒），对吞吐量有一定损耗。对于写入密集系统，需评估是否可以接受。
- 典型场景：电商订单、金融账户等不能容忍数据丢失的核心业务。
19.2.3 组复制（Group Replication）
异步和半同步复制都基于主-从角色，而组复制（MySQL Group Replication，简称 MGR）则是多主架构。它基于 Paxos 协议的实现，将多个 MySQL 实例组成一个复制组，组内任何一个节点都可以接受写操作，所有写入在组内达成一致后提交并复制给所有成员。
核心特点：
- 多主写入：任何成员都可以接收事务，组内使用共识算法确保所有提交在全局顺序一致。
- 自动故障检测与恢复：成员故障会被自动踢出组，恢复后自动加入，数据自动同步。不需要外部工具手动切换。
- 强一致性：事务在组内多数节点确认后才会真正提交，默认采用“AFTER”模式，即事务在多数节点写入中继日志后才返回成功，保证数据不丢。
- 冲突检测：多主模式下，两个节点并发修改同一行可能冲突，组复制有内置的行级冲突检测，冲突的事务会回滚。
模式选择：
- 单主模式：组内只有一个节点作为主库接受写，其他为只读。这个主库故障时组自动选新主库。此模式兼容性强，应用程序无需改造。
- 多主模式：所有成员均可写，需要应用处理冲突（很少直接使用）。
配置门槛：
组复制需要额外的系统变量配置，包括组内通信端口、种子成员地址、事务一致性级别（group_replication_consistency）等。InnoDB Cluster 将组复制与 MySQL Shell、MySQL Router 结合，降低了部署和管理难度。
实用要点：
- 组复制是 MySQL 原生高可用的理想方案，但学习成本和运维复杂度明显高于传统主从。适合对可用性和数据一致性要求极高的业务，并有能力投入运维资源的团队。
- 性能：多一次共识协商延迟，但整体吞吐量在多主下可以线性扩展。单主模式写入性能与半同步相近或略低。
- 故障切换：接近秒级，优于传统的 MHA 手动切换。
- 扩展性：组内成员不宜过多（建议不超过 9 个），否则共识开销增大。
三种模式对比速览：
| 模式 | 数据一致性 | 性能影响 | 架构复杂度 | 典型场景 |
|------|------------|----------|-------------|----------|
| 异步复制 | 可能丢失 | 极小 | 低 | 读多写少、备份、报表 |
| 半同步复制 | 至少一个从库不丢 | 中等 | 中 | 核心业务、不能丢数据 |
| 组复制 | 强一致（多数派） | 较高 | 高 | 金融、关键系统、零宕机要求 |
在实际工作中，多数公司的主从架构从异步开始，当业务发展到需要更强的数据保护时升级到半同步。而组复制通常在新系统建时就规划进去，避免后期迁移的复杂工作。选择哪种模式，本质是在性能、数据安全和运维成本三者之间找到一个平衡点。