异步复制快但不保险，主库提交后立即返回，从库异步拉取回放；半同步需至少一个从库落盘relay log才提交，兼顾安全与性能，mysql 5.7起推荐after_sync模式。
异步复制：快但不保险，主库提交后直接返回
异步复制是 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 校验数据一致性——这些比单纯打开半同步重要得多。
