MySQL半同步复制自动降级是超时触发的主动保底行为：主库提交事务时若未在rpl_semi_sync_master_timeout内收到任一从库ACK，立即降级为异步，不阻塞、不报错、不依赖从库状态；Rpl_semi_sync_master_status=OFF仅反映当前模式，需结合Rpl_semi_sync_master_off_times等状态变量诊断。
MySQL 半同步复制自动降级不是故障，是超时机制触发的主动保底行为——主库等不到 ACK 就切异步，避免写阻塞。
半同步降级发生在主库提交事务时
降级动作只在主库执行 COMMIT 的瞬间发生，和从库的 SHOW SLAVE STATUS 状态完全无关。即使从库 Slave_IO_Running: Yes、Seconds_Behind_Master: 0，主库也可能早已退为异步。
- 主库线程提交事务后，向已注册的半同步从库发起 ACK 请求
- 只要在
rpl_semi_sync_master_timeout毫秒内未收到任一从库响应，立即降级 - 降级后主库继续处理后续请求，不阻塞、不报错、不记录 error log
- 从库端无感知，IO 线程照常拉日志，SQL 线程照常回放
Rpl_semi_sync_master_status = OFF 不代表配置错了
这个状态变量反映的是“当前是否处于半同步模式”，但它的变化是结果而非原因。它为 OFF 只说明上一次或最近几次提交已触发降级，不能反推插件没装、参数没开或从库没连上。
- 必须查主库的
SHOW STATUS LIKE 'Rpl_semi_sync%'，重点关注：Rpl_semi_sync_master_off_times（因超时关闭次数）、Rpl_semi_sync_master_wait_timeouts（单次等待失败数） -
Rpl_semi_sync_master_no_times持续上涨，说明降级频繁；若几乎不涨但Rpl_semi_sync_master_off_times稳定增长，说明从库响应慢而非网络抖动 -
SHOW VARIABLES LIKE 'rpl_semi_sync%'只看配置值，不能替代运行态监控
rpl_semi_sync_master_timeout 设太小或太大都会出问题
默认值 10000（10 秒）在多数生产场景下既太保守又太危险：跨机房易误降级，高负载从库又可能让主库卡住太久。
- 实测依据应是 P95 网络 RTT + 从库
relay log写盘耗时（可用SHOW PROFILE FOR QUERY查 I/O 线程 fsync 阶段） - 建议初始设为
2000～5000，上线后观察Rpl_semi_sync_master_off_times：24 小时内增长 > 3 次，说明 timeout 偏小 - 用
iperf -c 从库IP -t 30 -u测 UDP 丢包率比 ping 更贴近 ACK 行为；丢包 > 0.1% 就会让100这类低值频繁失效
降级后不会自己恢复，得靠新事务触发重试
主库不会轮询、不发心跳、不检测从库状态，它安静地等下一个 COMMIT 来重新走一遍等待流程。如果主库空闲，Rpl_semi_sync_master_status 就一直卡在 OFF。
- 监控发现
Rpl_semi_sync_master_status = OFF时，必须立刻执行轻量事务，例如：INSERT INTO heartbeat (ts) VALUES (NOW()); - 也可在从库执行
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;，但前提是插件已启用且 relay_log 非空 - GTID 环境下，从库必须先启用插件、再启动 IO 线程；否则握手阶段错过，永远进不了半同步
最易被忽略的一点：半同步只保证事务落盘到从库的 relay log，不保证已执行。从库 SQL 线程卡住时，主库仍认为“已确认”，但数据实际还没应用——这和降级无关，却是数据可见性的真实瓶颈。
