半同步复制不能防止所有数据丢失，但能显著降低主库宕机时未同步事务丢失的概率；最常见配置失败原因是插件名与MySQL版本不匹配或从库未重启IO线程。
半同步复制不能防止所有数据丢失，但能显著降低主库宕机时未同步事务丢失的概率；配置失败的最常见原因是插件名与 MySQL 版本不匹配，或从库未重启 IO 线程。
MySQL 8.0.26+ 必须用新插件名，旧版用老名
MySQL 8.0.26 起废弃了 rpl_semi_sync_master/rpl_semi_sync_slave，改用 rpl_semi_sync_source 和 rpl_semi_sync_replica。混用会导致插件加载失败或状态始终为 OFF。
- MySQL 8.0.26 及以上（推荐）：
INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so'; INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
- MySQL 5.7–8.0.25（含）：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
执行 SHOW PLUGINS LIKE '%semi%' 后，确认 Status 列为 ACTIVE，且 Type 为 SEMISYNCHRONOUS_REPLICATION。
动态启用后必须重启从库 IO 线程
仅执行 SET GLOBAL rpl_semi_sync_replica_enabled = 1 不生效——半同步插件在从库上依赖 IO 线程启动时加载，不重启线程就等于没启用。
- 在从库执行：
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
之后检查 SHOW STATUS LIKE 'Rpl_semi_sync_replica_status'，返回 ON 才算真正激活。若仍为 OFF，大概率是插件名错、SO 文件缺失，或主从之间网络不通（尤其注意防火墙是否放行 3306 的 ACK 包）。
rpl_semi_sync_master_wait_point 决定一致性强度
这个变量控制主库在哪个阶段等待从库 ACK，直接影响崩溃后能否保证“已提交即已复制”：
-
AFTER_SYNC（MySQL 5.7+ 默认）：写完 binlog 后等待 ACK，再提交事务 → 主库 crash 后，所有已提交事务一定存在于至少一个从库 relay log 中 -
AFTER_COMMIT（5.5/5.6 默认）：先提交事务，再等 ACK → 主库 crash 时，可能有已提交但未发送到从库的事务丢失
建议显式设为 AFTER_SYNC：
SET GLOBAL rpl_semi_sync_source_wait_point = 'AFTER_SYNC';
该设置需在主库执行，且仅对后续事务生效；它不改变超时行为，但决定了数据安全边界。
超时降级不是故障，但会掩盖问题
rpl_semi_sync_source_timeout 默认 10000 毫秒（10 秒），超时后自动切回异步模式，Rpl_semi_sync_source_status 变为 OFF，但复制本身仍在继续。这容易让人误以为“半同步还在工作”，实际已退化。
- 查超时次数：
Rpl_semi_sync_source_no_times持续增长，说明网络延迟高或从库 I/O 压力大 - 查未确认事务数：
Rpl_semi_sync_source_no_tx非零，说明有事务卡在等待 ACK 阶段 - 不要盲目调大 timeout —— 它只是缓解阻塞，不能解决根本原因（如从库磁盘慢、relay log 写满、网络抖动）
真正关键的是监控 Rpl_semi_sync_source_clients：值为 0 表示没有从库在线支持半同步，此时整个机制形同虚设。
