异步复制适用于业务能容忍主库宕机丢失最近几秒事务且从库延迟可控（如seconds_behind_master稳定在1秒内）的场景；它开箱即用、无插件依赖、吞吐最高，适合报表分析、缓存预热、日志归档等对实时性不敏感的应用。
异步复制什么时候能用？
只要业务能容忍主库宕机后丢失最近几秒事务，且从库延迟在可接受范围内（比如Seconds_Behind_Master稳定在1秒内），异步复制就足够。它开箱即用、无插件依赖、吞吐最高，适合报表分析、缓存预热、日志归档这类对数据实时性不敏感的场景。
常见错误现象：SHOW SLAVE STATUS\G里Slave_IO_Running或Slave_SQL_Running为No，还强行切半同步——结果主库事务卡住，应用报超时。
- 必须确保
log_bin已开启，server-id主从不重复 - 从库账号要有
REPLICATION SLAVE权限，网络端口通 - 避免使用
binlog-do-db等库级过滤规则，否则可能漏同步、ACK不触发
半同步复制真正起效的前提是什么？
不是装了插件就自动生效。它完全依赖底层异步复制链路健康：主库binlog得发出去，从库IO_THREAD得拉得到，SQL_THREAD得重放得动。任何一环卡住，半同步就退化成“假同步”——状态显示ON，但实际Rpl_semi_sync_master_clients为0，主库悄悄降级为异步。
典型误操作：主库rpl_semi_sync_master_enabled = 1，但从库忘了装rpl_semi_sync_slave插件，或装错成rpl_semi_sync_master；又或者从库没执行STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;，导致状态不更新。
- 主库查插件：
SHOW PLUGINS LIKE '%semi%'，确认rpl_semi_sync_master状态是ACTIVE - 从库同样查，确认
rpl_semi_sync_slave是ACTIVE - 主库执行
SELECT @@rpl_semi_sync_master_wait_point，必须是AFTER_SYNC（5.7默认值，但动态改过可能变） - 主库
rpl_semi_sync_master_timeout建议设为1000（1秒），别用默认10000
为什么半同步不能保“零丢失”？
它只保证“最多丢一个事务”，不是绝对零丢失。主库崩溃瞬间，若事务刚写完binlog但还没来得及发给从库，或从库收到但relay log没刷盘就断电，这个事务仍会丢失。真正的零丢失需要Group Replication或InnoDB Cluster这类多节点共识机制。
容易被忽略的点：Rpl_semi_sync_master_status可能长期为ON，但Rpl_semi_sync_master_no_tx持续增长——说明超时频繁发生，实际已在异步模式下运行，RPO已失效。必须监控这两个状态变量，不能只看是否ON。
-
Rpl_semi_sync_master_no_tx每分钟增长 > 0，意味着降级发生 -
Rpl_semi_sync_master_clients应始终 ≥ 1，为0说明没有可用半同步从库 - 网络抖动、磁盘慢、从库负载高都可能导致ACK延迟，触发超时
MySQL 8.0 和 5.7 混合部署时要注意什么？
8.0 把半同步插件名改了：rpl_semi_sync_source和rpl_semi_sync_replica，不再是master/slave命名。如果5.7主库配8.0从库，必须在从库启动时加--skip-rpl-semi-sync，或配置文件里写loose-rpl-semi-sync-source-enabled = OFF，否则从库加载插件失败，复制直接起不来。
另一个坑：5.7主库没开GTID，8.0从库却设了enforce_gtid_consistency = ON，START SLAVE会直接报错拒绝启动。
- 检查主库是否开GTID：
SELECT @@gtid_mode，若为OFF，从库就不能强制GTID - 8.0从库配置中禁用半同步相关参数，避免与5.7主库插件名冲突
- 用
mysqlbinlog对比主从binlog和relay log内容，验证日志一致性
