mysql 5.7半同步复制不保证强一致性，仅承诺至少一个从库写入relay log；必须设after_sync模式、主从分装插件、重启io线程并验证rpl_semi_sync_master_status=on且clients≥1才生效。
MySQL 5.7 的半同步复制不是“开了就强一致”，它只承诺「至少一个从库已写入 relay log」，不保证执行、不防延迟、更不防主库崩溃丢事务——真要接近零丢失，得上 Group Replication。
半同步的两种 wait_point 模式决定数据是否“无损”
关键区别在事务提交顺序，直接影响主库宕机时能否回滚未确认事务：
-
AFTER_SYNC（MySQL 5.7 推荐）：binlog 刷盘 → 发送并等待 ACK → InnoDB 层才 commit。主库崩溃时，未收到 ACK 的事务在引擎层尚未提交，从库有 relay log 可顶上，实现“最多丢 0 个已确认事务” -
AFTER_COMMIT（5.6 默认）：binlog 刷盘 → InnoDB commit → 再发 binlog 并等 ACK。主库崩溃后，已 commit 但未发 ACK 的事务会丢失，且从库没 relay log，无法补全
必须显式设置：SET GLOBAL rpl_semi_sync_master_wait_point = 'AFTER_SYNC'；仅开 rpl_semi_sync_master_enabled = 1 不够，它默认仍是 AFTER_COMMIT。
插件安装和启用必须严格分主从，不能混用
主库和从库加载的是不同插件文件，装错或漏装，状态永远是 OFF：
- 主库执行：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so' - 从库执行：
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so' - 装完立刻查：
SHOW PLUGINS LIKE '%semi%'，两行都必须是ACTIVE - 从库装完后必须重启 IO 线程：
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;，只START SLAVE不触发 ACK 通道
某些 Docker 镜像或精简版会删掉 semisync_master.so 或 semisync_slave.so，需先查 SELECT @@plugin_dir 确认文件存在且可读。
验证状态不能只看变量，要看运行时指标
SHOW VARIABLES LIKE 'rpl_semi%' 全是 ON，不代表半同步在工作；真正生效要看 SHOW STATUS LIKE 'Rpl_semi_sync%'：
-
Rpl_semi_sync_master_status和Rpl_semi_sync_slave_status必须同时为ON -
Rpl_semi_sync_master_clients≥ 1，否则说明从库没连上来或 ACK 通路不通 - 常见失效原因：网络防火墙拦截 ACK 端口（默认 3306）、主从时间不同步超 30 秒、从库
log_slave_updates = 0（导致无法作为下级主库转发 ACK）
超时参数 rpl_semi_sync_master_timeout 建议设为 3000（3 秒），太小（如 100）会频繁降级为异步，太大（如 10000）会让业务明显卡顿。
最容易被忽略的是：半同步依赖稳定异步复制先行。如果 SHOW SLAVE STATUS\G 中 Slave_IO_Running 或 Slave_SQL_Running 是 No，或 Seconds_Behind_Master 持续 > 1，半同步就是空谈——它只是叠加机制，不是修复工具。
