如何借助MySQL半同步复制的增强版提高数据零丢失风险？

半同步复制不能实现数据零丢失，最多保证最多丢一个事务；其“增强版”依赖MySQL 5.7+的AFTER_SYNC模式、GTID、多从库ACK及低超时（1000ms）四者缺一不可，且必须重启IO线程、正确设置wait_point、监控降级指标才能真正生效。

半同步复制本身不能实现“数据零丢失”，它最多保证“最多丢一个事务”；所谓“增强版”本质是 MySQL 5.7+ 的 AFTER_SYNC 模式 + GTID + 多从库 ACK + 低超时的组合配置，缺一不可。

为什么 SHOW STATUS LIKE 'Rpl_semi_sync_*_status' 总是 OFF

这不是插件没装，而是插件逻辑根本没加载进线程。半同步在从库侧只在 IO 线程启动时初始化，仅执行 SET GLOBAL rpl_semi_sync_slave_enabled = 1 或 rpl_semi_sync_replica_enabled = 1 完全无效。

• 必须显式重启 IO 线程：STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
• MySQL 8.0.26+ 要用 semisync_replica.so 和 rpl_semi_sync_replica，混用旧名（slave）会导致插件状态为 DISABLED 或 ACTIVE 但不生效
• 检查 SELECT @@plugin_dir 后，确认对应 SO 文件真实存在，Linux 下大小写敏感、扩展名必须是 .so
• 防火墙需放行主库 3306 端口对从库 IP 的双向 TCP ACK 流量，不只是初始连接

rpl_semi_sync_master_wait_point 必须设为 AFTER_SYNC

这个参数决定主库在事务生命周期哪个点等待 ACK —— 它直接划清“已提交即已落盘”的安全边界。

• AFTER_COMMIT（5.6 及以前默认）：主库先提交再发 binlog → 崩溃时已提交但未发出的事务必然丢失
• AFTER_SYNC（5.7+ 默认）：主库写完 binlog → 等至少一个从库写入 relay log → 再提交 → 崩溃时，所有已提交事务一定存在于至少一个从库 relay log 中
• 主库执行：SET GLOBAL rpl_semi_sync_source_wait_point = 'AFTER_SYNC';（8.0.26+）或 SET GLOBAL rpl_semi_sync_master_wait_point = 'AFTER_SYNC';（≤8.0.25）
• 该设置对后续事务生效，不影响正在运行的事务

关键参数必须调低且配齐

默认值全是为兼容性妥协的，生产环境尤其金融场景必须手动收紧。

• rpl_semi_sync_master_timeout = 1000：超时单位毫秒，不是默认 10000；超过即降级异步，1 秒是平衡安全与阻塞的底线
• rpl_semi_sync_master_wait_for_slave_count = 2：强制等待两个从库 ACK，避免单点网络抖动导致降级
• 必须启用 GTID：gtid_mode = ON 且 enforce_gtid_consistency = ON，否则故障切换时位点易错乱
• 主库 my.cnf 中需固化：rpl_semi_sync_source_enabled = 1（8.0.26+）或 rpl_semi_sync_master_enabled = 1（≤8.0.25）

监控不能只看 “ON/OFF”，要看降级频率

半同步会自动降级为异步，状态长期显示 ON 只说明插件加载了，不代表每笔事务都走半同步路径。

• 重点监控：Rpl_semi_sync_master_no_times（降级次数）、Rpl_semi_sync_master_no_tx（降级事务数）
• 若这两项持续增长，说明网络延迟或从库 relay log 写入慢，不是配置问题，而是基础设施瓶颈
• Rpl_semi_sync_master_clients 应稳定 ≥2；若频繁归零，检查从库 IO 线程是否异常中断或插件被意外卸载
• MySQL 9.6.0 起引入 container_aware 启动选项，容器环境下务必启用，否则 ACK 包可能因网络命名空间隔离失败

真正难的不是配通，而是让 AFTER_SYNC 在每笔事务里都生效、让两个 ACK 在 1 秒内稳定抵达、让 GTID 在主从切换时不跳变——这些环节环环相扣，任意一环松动，“增强”就退化成普通半同步。