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，主库也始终异步运行。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 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 线程，否则永远无法进入半同步流程。