异步复制（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 的前提，光配复制模式没用。
