如何在MySQL 5.7中利用增强半同步复制实现强一致？

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。启用流程如下：

1. 主库执行：INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
2. 从库执行：INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
3. 主库设为启用：SET GLOBAL rpl_semi_sync_master_enabled = 1;
4. 从库设为启用：SET GLOBAL rpl_semi_sync_slave_enabled = 1;
5. 重启从库 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，但没有任何日志告警。若监控只看“插件已装”，就可能误判为始终半同步。

1. 主库设超时：SET GLOBAL rpl_semi_sync_master_timeout = 1000;
2. 强制要求至少一个从库响应：SET GLOBAL rpl_semi_sync_master_wait_for_slave_count = 1;（默认即 1，但显式设更稳妥）
3. 避免因瞬时抖动频繁降级：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 线程未重载，主库仍走异步路径。真正有效的验证组合是：

1. SHOW STATUS LIKE 'Rpl_semi_sync_master_yes_tx'; 值应随写入持续增长（非零且递增）
2. SHOW STATUS LIKE 'Rpl_semi_sync_master_no_tx'; 应长期为 0 或极低（说明极少降级）
3. SHOW STATUS LIKE 'Rpl_semi_sync_master_clients'; 至少返回 1（表示有从库成功注册为半同步节点）
4. 在从库上执行：SHOW SLAVE STATUSG，确认 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 双向通信）。

增强半同步 ≠ 强一致性，最易被忽略的三个事实

很多人以为开了增强半同步就“不会丢数据”，其实有三个硬性前提始终成立：

1. 它只保证事务写入从库的 relay log 并 fsync 落盘，不保证 SQL 线程已执行——从库延迟高时，Seconds_Behind_Master 可能达数分钟，此时主库已提交，但从库还没 apply
2. 它无法防止脑裂：主库网络分区后仍可写入，从库升主后形成双主，AFTER_SYNC 不提供冲突检测或自动仲裁
3. 它对单点故障无恢复能力：主库宕机后，必须人工或借助 MHA/Orchestrator 切换，切换窗口内新主可能缺失最后几个已半同步但未刷盘的事务（取决于 crash recovery 行为）

所以，真正要达成业务层的强一致，增强半同步只是基础一环，后面还得配 GTID、基于位点的切换校验、以及应用层幂等设计——这些都不是插件开关能解决的。