半同步复制解决异步复制下主库提交后从库未收到导致的数据丢失风险；需主从同时启用插件、重启io线程并确保relay_log启用；after_sync比after_commit更安全，推荐使用；超时降级后通过rpl_semi_sync_master_status和rpl_semi_sync_master_no_times监控判断。
半同步复制到底解决什么问题？
它解决的是异步复制下“主库提交了，但从库还没收到”导致的数据丢失风险。比如主库刚 COMMIT 一个转账事务，立刻宕机，而 binlog 还卡在网络或从库 IO 线程缓冲区里——这时切换到从库，钱就凭空消失了。半同步强制主库多等一步：至少一个从库把 binlog 写进 relay log 并刷盘（flush），才向客户端返回成功。
为什么装插件后还无效？常见激活失败原因
半同步不是装完插件就自动生效的，必须两端同时启用且 IO 线程重启。最容易漏的三步：
-
SET GLOBAL rpl_semi_sync_master_enabled = 1（主库）和SET GLOBAL rpl_semi_sync_slave_enabled = 1（从库）必须分别执行，缺一不可 - 从库必须显式重启 IO 线程：
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;—— 单纯START SLAVE不会重载半同步逻辑 - 确认从库的
relay_log已启用（relay_log非空值），否则即使插件开启，从库也无法写 relay log，自然无法发 ACK
AFTER_SYNC 和 AFTER_COMMIT 到底差在哪？
这是 MySQL 5.7+ 的关键分水岭，默认是 AFTER_SYNC，但行为差异直接影响故障时的数据一致性：
