半同步复制不能实现数据零丢失，最多保证最多丢一个事务；其“增强版”依赖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 在主从切换时不跳变——这些环节环环相扣，任意一环松动，“增强”就退化成普通半同步。
