mysql 5.7增强半同步复制（after_sync模式）是接近强一致的原生方案，需主从分别安装对应插件、启用参数、重启io线程，并验证rpl_semi_sync_master_clients≥1、rpl_semi_sync_master_yes_tx递增、rpl_semi_sync_master_no_tx趋零。
MySQL 5.7 的增强半同步复制（AFTER_SYNC 模式）是唯一能在主从架构中接近“强一致”的原生方案，但它不等于强一致性，而是把数据丢失风险压到理论最低——前提是配置正确、网络稳定、监控到位。
确认 MySQL 5.7 版本并启用 rpl_semi_sync_master 插件
5.7.17+ 原生内置插件，无需手动下载 semisync_master.so；但低于该版本需确认插件是否存在。执行前先检查：
SELECT VERSION();
若为 5.7.15 或更低，必须手动安装插件，否则 INSTALL PLUGIN 会报错 Plugin 'rpl_semi_sync_master' is not loaded。启用流程如下：
- 主库执行：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; - 从库执行：
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; - 主库设为启用：
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;（仅改enabled不生效）
关键参数必须调优：超时与降级行为
rpl_semi_sync_master_timeout 默认 10 秒，但生产环境建议设为 1000（1 秒）甚至更低。原因很实际：超时即降级为异步，而这个过程完全静默——Rpl_semi_sync_master_status 会从 ON 变成 OFF，但没有任何日志告警。若监控只看“插件已装”，就可能误判为始终半同步。
- 主库设超时：
SET GLOBAL rpl_semi_sync_master_timeout = 1000; - 强制要求至少一个从库响应：
SET GLOBAL rpl_semi_sync_master_wait_for_slave_count = 1;（默认即 1，但显式设更稳妥） - 避免因瞬时抖动频繁降级：
SET GLOBAL rpl_semi_sync_master_wait_no_slave = OFF;（设为ON会导致无从库时也卡住提交）
注意：rpl_semi_sync_master_wait_point 必须为 AFTER_SYNC（5.7 默认），不是 AFTER_COMMIT。可用 SHOW VARIABLES LIKE 'rpl_semi_sync_master_wait_point'; 验证。
验证是否真在 AFTER_SYNC 模式下运行
仅看 Rpl_semi_sync_master_status = ON 不够，因为即使启用了插件，若从库未注册或 IO 线程未重载，主库仍走异步路径。真正有效的验证组合是：
-
SHOW STATUS LIKE 'Rpl_semi_sync_master_yes_tx';值应随写入持续增长（非零且递增） -
SHOW STATUS LIKE 'Rpl_semi_sync_master_no_tx';应长期为0或极低（说明极少降级） -
SHOW STATUS LIKE 'Rpl_semi_sync_master_clients';至少返回1（表示有从库成功注册为半同步节点） - 在从库上执行：
SHOW SLAVE STATUS\G，确认Seconds_Behind_Master非 NULL，且Slave_SQL_Running_State不是 “Waiting for semi-sync ACK from master” 类似卡死状态
如果 Rpl_semi_sync_master_clients 为 0，常见原因是：从库未执行 START SLAVE IO_THREAD，或主库 my.cnf 中未开启 log_bin 和 server_id，或防火墙阻断了主库的 3306 端口反向 ACK 回包（半同步依赖 TCP 双向通信）。
增强半同步 ≠ 强一致性，最易被忽略的三个事实
很多人以为开了增强半同步就“不会丢数据”，其实有三个硬性前提始终成立：
- 它只保证事务写入从库的
relay log并 fsync 落盘，不保证 SQL 线程已执行——从库延迟高时，Seconds_Behind_Master可能达数分钟，此时主库已提交，但从库还没 apply - 它无法防止脑裂：主库网络分区后仍可写入，从库升主后形成双主，
AFTER_SYNC不提供冲突检测或自动仲裁 - 它对单点故障无恢复能力：主库宕机后，必须人工或借助 MHA/Orchestrator 切换，切换窗口内新主可能缺失最后几个已半同步但未刷盘的事务（取决于 crash recovery 行为）
所以，真正要达成业务层的强一致，增强半同步只是基础一环，后面还得配 GTID、基于位点的切换校验、以及应用层幂等设计——这些都不是插件开关能解决的。
