异步复制：快但不保险，主库提交后直接返回
异步复制是 MySQL 默认行为：主库写完
binlog、提交事务，立刻返回客户端成功，完全不等从库。从库靠自己的
IO_THREAD异步拉取日志，写入
relay log，再由
SQL_THREAD回放——三者全无阻塞依赖。
常见错误现象：
Master crash后切换到某个从库，发现刚提交的几条订单记录“凭空消失”；或者读写分离场景下，应用写完立刻去从库查，查不到最新数据。 适用场景：读多写少、允许短暂延迟（秒级甚至分钟级）、对吞吐量敏感的业务（如日志归档、报表库） 性能影响：几乎无额外开销，主库吞吐不受从库拖累 风险点：主库单点故障时，未同步的 binlog 会永久丢失
半同步复制：等一个从库落盘 relay log 才算提交成功
半同步不是“等从库执行完”，而是等至少一个从库把主库发来的 binlog 事件完整写入并
fsync到本地
relay log文件——这个动作叫“收到并落盘”，之后从库发
ACK给主库，主库才完成事务提交。
关键细节：
rpl_semi_sync_master_wait_for_slave_count默认为
1，可设为更高值（比如
2），但必须有对应数量的从库在线且支持半同步，否则主库会自动降级为异步模式。 适用场景：金融类写后即读、主备切换要求数据零丢失、审计合规强约束系统 性能影响：单次事务 RT 增加约 10–50ms（取决于网络延迟和从库 I/O），但远低于全同步 容易踩的坑：没在主库装
semisync_master.so插件，或从库没装
semisync_slave.so；配置后忘记重启
slave或执行
START SLAVE；超时参数
rpl_semi_sync_master_timeout设得太小（默认 10s），导致频繁降级
为什么不能只靠“主库等 ACK”就认为绝对安全？
MySQL 5.7 之前的半同步（
after_commit模式）存在一个边界问题：主库已提交事务、也收到了 ACK，但此时从库的
SQL_THREAD还没开始回放，如果主库紧接着宕机、又立刻切走流量，新主库上该事务虽在 relay log 里，却尚未生效——应用仍可能读不到。
MySQL 5.7 引入增强半同步（
after_sync模式）解决了这点：主库把事务写入 binlog 后，先不提交，而是等至少一个从库 ACK 落盘 relay log 后，再提交。这样即使主库崩了，只要那个 ACK 过的从库活着，它 relay log 里的事务就是“已确认 + 未提交”，切换后能保证数据不丢也不多。 检查当前模式：
SELECT @@rpl_semi_sync_master_wait_point;返回
AFTER_SYNC才是增强版 必须同时启用插件并设置变量：
SET GLOBAL rpl_semi_sync_master_enabled = ON;和
SET GLOBAL rpl_semi_sync_slave_enabled = ON;别忽略监控：
SHOW STATUS LIKE 'Rpl_semi_sync%';中的
Rpl_semi_sync_master_status和
Rpl_semi_sync_slave_status必须都为
ON
异步 vs 半同步，选哪个不是看“要不要一致性”，而是看“能接受什么代价”
半同步不是银弹。它提升的是“主库单点故障下的数据保底能力”，但无法解决从库延迟、网络分区、SQL 线程卡住等问题。如果你的从库本身负载高、磁盘慢、或者 SQL 回放有大事务阻塞，那即便启用了半同步，
relay log落盘也可能变慢，反而拖垮主库响应。
真正要落地，得配合：从库硬件不低于主库、关闭
sync_binlog=0风险、用
ROW格式 binlog 减少回放歧义、定期用
pt-table-checksum校验数据一致性——这些比单纯打开半同步重要得多。
