必须设为after_sync，否则rpo不可能为0：该模式下主库在innodb commit前强制等待至少一个从库将binlog刷盘至relay log，结合sync_binlog=1、innodb_flush_logs_at_trx_commit=1、插件正确安装及io线程重启等前提，才能真正实现rpo=0。
必须设为 AFTER_SYNC，否则 RPO 不可能为 0
MySQL 半同步复制中，rpl_semi_sync_source_wait_point 只有两个合法值：AFTER_SYNC 和 AFTER_COMMIT。只有设为 AFTER_SYNC 才可能实现 RPO=0；设成 AFTER_COMMIT 时，主库已提交事务但 binlog 还没发出去，宕机就丢数据。
关键流程差异：
-
AFTER_SYNC：写 binlog →fsync到磁盘 → 发送 → 等从库刷盘 relay log 的 ACK → 再执行 InnoDB commit → 返回客户端 -
AFTER_COMMIT：写 binlog →fsync→ InnoDB commit → 发送 → 返回客户端（此时 ACK 还没收到）
也就是说，AFTER_SYNC 下客户端收到“成功”时，事务日志已确定落盘至少一个从库；AFTER_COMMIT 下收到成功响应时，日志可能还在主库内存或网络途中。
插件名和变量名在 5.7.6+ / 8.0.26+ 必须用新命名
老教程里写的 rpl_semi_sync_master 和 rpl_semi_sync_slave 在新版 MySQL 中会直接报错，根本装不上。
主库要执行：
INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
从库要执行：
INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
对应启用开关也变了：
-
rpl_semi_sync_source_enabled（不是master_enabled） -
rpl_semi_sync_replica_enabled（不是slave_enabled） rpl_semi_sync_source_wait_point = 'AFTER_SYNC'
执行完 SHOW PLUGINS LIKE '%semi%'，Status 必须是 ACTIVE，Type 必须是 SEMISYNCHRONOUS_REPLICATION，否则后续所有 SET 都无效。
从库启用半同步必须重启 IO 线程
这是最常踩的坑：只在从库执行 SET GLOBAL rpl_semi_sync_replica_enabled = 1，然后查 Rpl_semi_sync_replica_status 仍是 OFF。
因为半同步插件依赖 IO 线程启动时加载，运行中改变量不触发重载。必须显式执行：
STOP SLAVE IO_THREAD;<br>START SLAVE IO_THREAD;
之后再查状态。若仍为 OFF，优先排查：
-
semisync_replica.so文件是否真实存在且路径正确 - 防火墙是否放行 TCP ACK 包（不只是 3306 连接，ACK 是独立包）
-
relay_log是否启用（relay_log = mysql-relay-bin）
sync_binlog=1 和 innodb_flush_logs_at_trx_commit=1 缺一不可
AFTER_SYNC 模式只是流程控制，真正保证“binlog 落盘”和“InnoDB 日志落盘”的，是这两个参数。如果其中任意一个设为 0 或 2，RPO=0 就失效。
例如：
-
sync_binlog=0：binlog 只写 OS cache，主库宕机即丢失 -
innodb_flush_logs_at_trx_commit=2：InnoDB log 只 fsync 到 OS cache，崩溃后可能丢最近 1 秒事务
这两个参数必须同时为 1，且需写入 my.cnf 并重启生效（仅 SET GLOBAL 不持久，重启后回退）。
RPO=0 不是单点配置问题，而是 AFTER_SYNC + 新版插件名 + IO 线程重启 + 两个 fsync 参数 + 网络可靠性的组合结果；漏掉任何一环，都只是“看起来像 RPO=0”。
