半同步复制不能防止所有数据丢失，但能显著降低主库宕机时未同步事务丢失的概率；关键在于ACK仅表示从库IO线程已将binlog写入relay log，而非SQL线程执行完成，且必须重启IO线程才能加载插件逻辑，插件名与MySQL版本严格匹配（8.0.26+用source/replica，旧版用master/slave），超时后自动降级为异步复制，需监控降级次数而非仅看状态是否ON。
半同步复制不能防止所有数据丢失，但能显著降低主库宕机时未同步事务丢失的概率；关键在于理解 ACK 是从库 IO 线程写入 relay log 后发出的信号，不是执行完成、也不是网络收到就确认。
为什么 SHOW STATUS LIKE 'Rpl_semi_sync_slave_status' 一直为 OFF
这是最常遇到的“配置成功但不生效”问题。根本原因不是插件没装，而是从库 IO 线程压根没加载半同步逻辑。
- 仅执行
SET GLOBAL rpl_semi_sync_slave_enabled = 1不触发加载 —— 插件只在 IO 线程启动时初始化 - 必须显式重启线程：
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD; - 检查
SELECT @@plugin_dir;确认semisync_replica.so（8.0.26+）或semisync_slave.so（≤8.0.25）文件真实存在 - 防火墙可能拦截了 ACK 包：主库 3306 端口需允许从库 IP 的 双向 TCP ACK 流量，不只是初始连接
INSTALL PLUGIN 失败：插件名与 MySQL 版本强绑定
MySQL 8.0.26 是分水岭，插件名和 SO 文件名全部变更，混用必报错或状态始终 OFF。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 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 - SO 文件名大小写敏感，Linux 下是
.so，macOS 是.dylib，不可硬套
rpl_semi_sync_source_wait_point 决定“已提交即已落盘”的边界
这个变量控制主库在事务生命周期哪个节点等待 ACK，直接决定崩溃后能否找回已提交事务。
-
AFTER_SYNC（5.7+ 默认）：主库写完 binlog → 等 ACK → 再提交 → 崩溃后，所有已提交事务一定存在于至少一个从库 relay log 中 -
AFTER_COMMIT（5.5/5.6 默认）：主库先提交 → 再等 ACK → 崩溃时，已提交但未发出去的事务会丢失 - 务必在主库执行：
SET GLOBAL rpl_semi_sync_source_wait_point = 'AFTER_SYNC'；该设置对后续事务生效，不影响当前正在运行的事务 - 它不改变超时行为，也不影响
rpl_semi_sync_source_timeout，但划清了数据安全底线
超时降级不是故障恢复，而是掩盖网络或从库 IO 延迟
Rpl_semi_sync_source_status 在超时后自动变为 OFF，看起来“还能用”，但实际已退化为异步复制 —— 这个状态本身不会报警，容易被忽略。
- 监控重点不是
Rpl_semi_sync_source_status是否为 ON，而是Rpl_semi_sync_source_no_tx（降级次数）和Rpl_semi_sync_source_timeouts（超时次数）是否持续增长 - 频繁降级大概率说明：从库 relay log 写入慢（磁盘 I/O 瓶颈）、主从网络 RTT >
rpl_semi_sync_source_timeout、或从库 IO 线程卡在某个 event 上 - 不要把
rpl_semi_sync_source_timeout设为 0（永不降级）—— 主库事务会无限阻塞，业务直接雪崩 - ACK 不代表数据已执行，只代表 relay log 落盘；SQL 线程延迟仍可能导致从库数据“可见滞后”
