MySQL 主从复制并不是一个单一开关，而是一组解决不同问题的机制：异步复制负责把变更传到副本，半同步复制缩短主库提交与副本接收之间的风险窗口，Group Replication（MGR）进一步提供组内一致性与自动选主能力，GTID 则让复制位点管理从文件名和偏移量转向事务标识。
如果只看"是否有副本"，很容易把数据复制、故障切换和脑裂防护混为一谈。更稳妥的做法是先明确业务能承受什么，再选择对应的复制方式。
先分清复制链路中的三个位置
一次事务从主库传到副本，通常会经过三个关键阶段：
- 主库执行事务并写入 binary log（Binlog）。Binlog 记录数据变更，是复制的输入。
- 副本的 I/O 线程从主库拉取 Binlog，写入本地 relay log。
- 副本的 SQL 线程读取 relay log，并在本地重放事务。
异步复制的特点是主库不等待副本完成上述过程就向客户端返回成功。因此，它的优点是写入延迟较低、架构简单；代价是主库突然故障时，最近提交的一部分事务可能还没有到达副本。这个风险可以用复制延迟和故障时的日志位置来衡量，而不能仅凭"有从库"来判断。
GTID 位于复制管理层。它为事务分配全局标识，并让副本通过已执行的 GTID 集合判断还缺哪些事务，减少主从切换时手工查找 Binlog 文件和位点的工作量。
半同步复制的关键：ACK 在提交前还是提交后
半同步复制要求主库在返回客户端前，至少等一个副本确认已经收到 Binlog。真正需要关注的不是"有没有 ACK"，而是主库存储引擎的提交发生在 ACK 前还是 ACK 后。
AFTER_COMMIT：延迟较小，但可见性窗口更复杂
AFTER_COMMIT 先提交主库事务，再等待副本确认。这样主库上的其他会话可能已经读到提交结果，但副本还没收到对应日志。如果主库在这个窗口内故障并切换到副本，客户端曾经看到的数据可能暂时不存在。
AFTER_SYNC：优先收敛主库与副本的提交视图
AFTER_SYNC 先将 Binlog 发送到副本并等待确认，再完成主库存储引擎提交。这样，主库对外可见的提交会更接近副本已经接收日志的时点，适合更关注故障切换后一致性的生产业务。它并不等于跨故障域的完整灾备：网络中断、副本故障、复制插件退化以及存储损坏仍然需要单独设计。
半同步复制适合已经有主备架构、希望降低 RPO 风险，又不急于引入自动选主的团队。需要同时监控半同步是否生效、等待 ACK 的延迟、复制线程状态和副本延迟；如果没有可用副本确认，系统可能退化为异步行为或影响写入可用性，具体取决于配置。
MGR 解决的是组内一致性与切换自动化
MySQL Group Replication 将多个 MySQL 实例组织成一个复制组。事务需要经过组内认证和排序，节点对事务顺序形成一致视图；网络分区时，无法形成多数派的成员不能继续像正常主节点那样推进写入，从而降低双主并行写入的风险。
MGR 常见两种模式：
- 单主模式：同一时间由一个节点接收写入，故障时由组内机制重新选择主节点。应用改造通常比多主模式简单，适合作为核心业务的高可用基础。
- 多主模式：多个节点都可写，但并发修改同一数据可能产生冲突，应用和数据模型需要为此负责。不能因为"节点都能写"就把它当作无成本的写扩展方案。
MGR 的代价是更高的部署和运维要求：节点间网络质量、成员数、多数派规则、故障摘除、恢复加入和应用连接路由都要纳入演练。对小型站点或可以接受人工切换的业务，直接上 MGR 未必划算。
GTID 为什么应该作为复制基础能力
使用传统文件位点时，切换前需要确认副本已经执行到哪个 Binlog 文件和偏移量；拓扑变化、日志清理或多级复制都会增加操作复杂度。GTID 以事务集合描述复制进度，副本可以向新主库请求自己尚未执行的事务。
从旧架构迁移到 GTID 时，不应直接修改到最终状态。通常需要按照兼容性阶段逐步切换，并确认所有副本、备份恢复流程和故障切换脚本都支持 GTID。真正重要的不是参数本身，而是把复制进度、切换流程和回滚路径纳入自动化测试。
按业务目标做选择
可以用下面的顺序判断：
- 能否接受故障时少量事务丢失？ 能接受时，异步复制通常足够；不能接受时，考虑 AFTER_SYNC 半同步或更强的一致性方案。
- 能否接受人工故障切换？ 如果可以，GTID 加半同步是相对直接的演进路径；如果需要减少人工介入，再评估 MGR。
- 应用是否能处理多主冲突和连接切换？ 不能时优先单主模式，避免把数据库层的能力转化为应用层不可控的复杂度。
- 上云后是否有跨可用区或跨地域要求？ 复制机制解决的是数据库节点之间的同步，不会自动替代备份、跨地域灾备、监控和恢复演练。
对个人站长和小团队，常见的落地顺序是：先做好备份与恢复验证，再用 GTID 管理复制位置；业务对 RPO 有要求时引入 AFTER_SYNC 半同步；只有在确实需要自动选主、且团队能承担集群运维时，再评估 MGR。这样可以避免为了"高可用"一次性引入过多组件。
MySQL 主从复制的选择，本质上是在写入延迟、故障切换速度、数据一致性和运维复杂度之间做取舍。把这几个指标分别拆开，再结合业务的 RPO、RTO 与团队能力，通常比直接套用某一种架构更可靠。