MySQL半同步复制是在主从延迟与数据安全性间折中的设计：主库提交事务后至少等待一个从库将事务写入relay log并返回ACK才响应客户端，超时则自动降级异步，恢复后自动升回，兼顾可用性与基本数据安全。
MySQL 半同步复制不是“要么全同步、要么异步”的二选一，而是在主从延迟与数据安全性之间做的一种折中设计：主库在返回客户端成功前，至少等待一个从库确认已收到并写入 relay log（注意不是已执行完），从而避免主库崩溃时丢失尚未同步的事务。
半同步复制的核心逻辑
半同步复制依赖插件实现（semisync_master 和 semisync_slave），其关键行为如下：
- 主库提交事务后，不会立即返回客户端，而是向已注册的半同步从库发起 ACK 请求
- 只要有一个从库返回“已接收并落盘 relay log”，主库就认为本次提交成功，继续响应客户端
- 若超时（默认 10 秒，由 rpl_semi_sync_master_timeout 控制）未收到任何 ACK，主库自动降级为异步复制，继续提供服务
- 当有从库重新满足半同步条件（如网络恢复、插件重启），主库会自动升回半同步模式
与异步、全同步的本质区别
对比更清晰地体现半同步的定位：
- 异步复制：主库写完 binlog 就返回，不关心从库状态；性能最好，但主库宕机可能丢事务
- 半同步复制：主库确保至少一个从库“接住”事务（relay log 持久化），兼顾可用性与基本数据安全
- 组复制（MGR）或 XtraDB Cluster：真正全同步——所有节点达成共识才提交，强一致性但性能开销大、部署复杂
启用与验证要点
开启半同步需主从两端配合，且注意版本兼容性（MySQL 5.7+ 原生支持，5.5/5.6 需安装官方插件）：
- 主库执行：INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';，再设 SET GLOBAL rpl_semi_sync_master_enabled = 1;
- 从库执行：INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';，再设 SET GLOBAL rpl_semi_sync_slave_enabled = 1;，并重启 IO 线程（STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;）
- 验证是否生效：SHOW VARIABLES LIKE '%semi_sync%'; 查看 enabled 状态，SHOW STATUS LIKE 'Rpl_semi_sync%'; 观察统计值（如 Rpl_semi_sync_master_status 为 ON 表示当前处于半同步模式）
实际使用中的常见问题
半同步看似简单，但几个细节容易被忽略：
- 超时降级是静默的：一旦超时，主库自动切回异步，监控不到位可能误以为仍具备半同步保障
- 仅保证 relay log 写入，不保证执行：从库可能因 SQL 线程卡住导致延迟，但只要 IO 线程已持久化，主库就认为 OK
- 不解决脑裂或自动选主：它只是复制机制增强，高可用仍需配合 MHA、Orchestrator 或 MySQL Router 等工具
- 性能影响有限但存在：单次提交增加一次网络往返（主→从→主），在高并发小事务场景下 RT 可能上升 1–3ms，需结合业务容忍度评估
