异步复制适合读多写少且容忍数据丢失的场景，MySQL默认采用，主库不等从库确认即返回成功，可能导致数据丢失；半同步复制在一致性与可用性间折中，需至少一个从库落盘后才提交；组复制基于Paxos实现强一致多写，但性能开销大、限制多。
异步复制（ASYNC）适合读多写少、能容忍数据丢失的场景
MySQL 默认就是异步复制：binlog 写完就返回客户端成功，不等从库回执。主库崩溃时，最后几条事务很可能没传到从库，造成数据丢失。
常见错误现象：Seconds_Behind_Master 突然飙升、主从延迟几十秒甚至几分钟，但业务无感知；切换主库后发现新主库缺了几笔订单。
- 适用场景：报表分析库、搜索同步库、日志归档库这类“最终一致即可”的下游
- 不适用场景：金融交易、账户余额、支付结果通知等强一致性要求场景
- 性能影响最小，吞吐最高，网络抖动几乎不影响主库响应
半同步复制（SEMISYNC）在可用性与一致性间折中
启用 rpl_semi_sync_master_enabled=ON 后，主库至少等待一个从库写入 relay log 并刷盘（默认配置下），才向客户端返回成功。
注意：MySQL 5.7+ 的 rpl_semi_sync_master_wait_point 默认是 AFTER_SYNC，即等从库落盘后再提交主库事务——这是真正意义的“半同步”；若设为 AFTER_COMMIT（5.6 默认），主库已提交再等从库，仍可能丢事务。
- 必须安装插件：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so' - 超时由
rpl_semi_sync_master_timeout控制（单位微秒），超时自动退化为异步，不阻塞主库 - 从库宕机或网络中断时，主库最多卡住 timeout 时间，之后继续异步运行，这点常被误认为“不可靠”
组复制（Group Replication）适合高一致性、多写需求，但代价明显
group_replication 是 MySQL 官方的 Paxos 实现，要求至少 3 节点，所有写入需多数派确认（quorum）才提交，天然支持多主写（multi-primary 模式）和自动故障转移。
但它的限制很硬：必须用 innodb 引擎、关闭 binlog_format=ROW 不可改、禁止 CREATE TABLE ... SELECT、禁止外键级联操作——线上迁移前务必全量 SQL 兼容性扫描。
- 网络要求高：节点间延迟超过
group_replication_member_expel_timeout（默认 0，即立即驱逐）会触发脑裂保护 - 写性能下降明显，尤其跨 IDC 部署时，RT 增加常达 10–50ms
- 不是“开箱即用”，需要手动管理
group_replication_group_name、group_replication_local_address等 10+ 个参数
真正决定选型的不是功能列表，而是你的故障恢复 SLO
很多人花大量时间对比参数，却没想清楚一个问题：如果主库宕机，你能接受多少秒的数据丢失？多少秒的服务不可用？
异步复制下 RPO（恢复点目标）可能是分钟级；半同步通常控制在秒级（取决于 timeout 设置）；组复制可做到 0 丢失（RPO=0），但 RTO（恢复时间目标）不一定快——因为选主、状态同步、应用 relay log 都要时间。
最容易被忽略的一点：无论哪种模式，relay_log_recovery=ON 必须开启，否则从库意外重启后可能重复执行或跳过事务；而 sync_binlog=1 和 innodb_flush_log_at_trx_commit=1 才是主库不丢 binlog 的前提，光配复制模式没用。
