MySQL 8.0异地双活必须设rpl_semi_sync_source_wait_point=AFTER_SYNC，严格匹配插件名与SO文件（8.0.26+用source/semisync_source.so），从库需显式配置relay-log、read_only=ON并重启IO线程，否则Rpl_semi_sync_slave_status恒为OFF且主库实际异步运行。
异地双活场景下，MySQL 8.0 半同步复制不能直接照搬同城主从配置——网络延迟高、链路不稳定、故障切换频繁，会导致半同步频繁超时降级，甚至掩盖真实同步异常。必须把 rpl_semi_sync_source_wait_point 设为 AFTER_SYNC，且主从插件版本、SO 文件名、IO 线程加载时机全部对齐，否则 Rpl_semi_sync_master_status 显示 ON 也可能是假象。
主库插件名和 SO 文件必须严格匹配 MySQL 8.0.x 小版本
MySQL 8.0.26 是分水岭：低于该版本用 rpl_semi_sync_master + semisync_master.so；8.0.26 及以上必须用 rpl_semi_sync_source + semisync_source.so。混用会静默失败——SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS 可能显示 ACTIVE，但实际不参与握手。
验证步骤：
- 查版本：
SELECT VERSION(); - 装插件（以 8.0.33 为例）：
INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so'; - 确认 SO 文件真实存在：
SELECT @@plugin_dir;进入该路径检查文件名是否完全一致（Linux 区分大小写） - 查状态：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%';，状态必须是ACTIVE
从库 Rpl_semi_sync_slave_status 永远 OFF 的真实原因
不是插件没装，而是 IO 线程启动时未加载半同步逻辑。即使已执行 SET GLOBAL rpl_semi_sync_slave_enabled = 1，变量值变了，但线程不会自动重载插件。
必须满足三个硬性前提并重启 IO 线程：
-
relay-log必须显式配置（如relay-log = relay-bin），不能依赖默认值 -
read_only = ON必须在配置文件中设置，且生效（SELECT @@read_only;返回 1） - 执行：
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;，强制重建连接并触发半同步握手
缺任一条件，Rpl_semi_sync_slave_status 永远为 OFF，主库也始终异步运行。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
rpl_semi_sync_source_wait_point = AFTER_SYNC 是数据不丢失的底线
这个参数决定主库崩溃时，已返回客户端的事务是否一定存在于从库。设成 AFTER_COMMIT（旧默认）等于白配：主库写 binlog → 提交 → 再等 ACK，崩溃后提交已落盘但 ACK 未收，事务丢失。
AFTER_SYNC 流程是：写 binlog → 等至少一个从库写入 relay log 并 ACK → 再提交 → 返回客户端。只要 ACK 成功，事务就已在从库中继日志里，可恢复。
配置方式（主库）：
- 动态设置：
SET GLOBAL rpl_semi_sync_source_wait_point = 'AFTER_SYNC'; - 持久化到配置文件：
rpl_semi_sync_source_wait_point = AFTER_SYNC - 必须在插件启用后设置，否则无效
异地链路必须监控降级行为，不能只看状态是否 ON
半同步在高延迟链路上大概率超时降级，但 Rpl_semi_sync_master_status 仍显示 ON（它只表示插件已启用，不反映当前是否真在半同步模式）。真正要盯的是：
-
Rpl_semi_sync_master_no_times：累计降级次数，突增说明网络或从库异常 -
Rpl_semi_sync_master_timeouts：超时次数，结合rpl_semi_sync_source_timeout值判断是否合理（异地建议设 5000–10000ms） -
Seconds_Behind_Master持续 >30s 且Rpl_semi_sync_master_status=ON，基本可判定已静默降级
最易被忽略的一点：GTID 模式下，如果主从已运行多日再加半同步插件，IO 线程早已建连完成，错过初始握手阶段——必须重启 IO 线程，否则永远无法进入半同步流程。
