rpl_semi_sync_master_status在on/off间跳变不是插件故障，而是半同步机制主动暴露网络抖动或从库响应异常；根本原因是rpl_semi_sync_master_timeout设置不当（如100ms）与实际rtt峰值、tcp队列积压等不匹配，导致ack超时降级，需结合rpl_semi_sync_master_off_times和rpl_semi_sync_master_no_times综合判断瓶颈。
这不是插件故障，而是半同步机制在主动暴露网络或从库响应异常
为什么Rpl_semi_sync_master_status会在ON/OFF间跳变
主库的Rpl_semi_sync_master_status从ON变成OFF，本质不是“坏了”，而是它在告诉你：至少一次等待ACK超时了。MySQL半同步不追求“永远不降级”，而是“只在能稳住的时候才坚持”。一旦rpl_semi_sync_master_timeout设得太紧（比如100ms），而实际网络RTT峰值已达3–5ms、叠加从库TCP接收队列积压，就必然频繁触发降级。
- 每次降级都会记录到
Rpl_semi_sync_master_off_times，这个值每小时涨几十次，说明问题不在参数，而在底层 -
Rpl_semi_sync_master_no_times持续增长，代表半同步尝试失败次数——它和off_times一起看，才能判断是偶发抖动还是系统性瓶颈 - 仅查
rpl_semi_sync_master_enabled = 1没用，必须查SHOW STATUS LIKE 'Rpl_semi_sync%'里的运行时状态
rpl_semi_sync_master_timeout设成多少才算合理
它不是越长越安全，而是要落在真实网络与负载的波动区间内。设错会放大风险：太短 → 频繁降级；太长 → 单事务延迟不可控，业务卡顿。
- 局域网（RTT稳定在0.5–2ms）：起点设
1000（1秒），覆盖99%尖峰抖动足够 - 跨机房或高负载（RTT偶发飙到15ms+）：可设
3000～5000，但别碰10000（默认值），否则一个事务可能卡10秒 - 绝对不要设低于
500：UDP小包丢包率＞0.1%时，100ms超时几乎必降级 - 改完立即生效：
SET GLOBAL rpl_semi_sync_master_timeout = 3000;，无需重启
AFTER_SYNC模式下，为什么网络波动仍会导致降级
哪怕用了rpl_semi_sync_master_wait_point = AFTER_SYNC（即事务提交前等ACK），也不能避免降级。因为“等ACK”这一步本身依赖网络和从库IO能力——它只是把数据丢失风险降到零，但没解决传输稳定性问题。
- 从库
net.ipv4.tcp_rmem过小，导致ACK包被内核丢弃或延迟，主库收不到，只能超时 - 从库正在执行大查询或备份，
Slave_IO_Running: Yes但Seconds_Behind_Master持续上涨，说明relay log写入已滞后 - 从库开启了并行复制（
slave_parallel_workers > 0）但slave_parallel_type = DATABASE，SQL线程未执行完就提前发了ACK，主库误判成功 - 主库看到
Rpl_semi_sync_master_clients ≥ 1，不代表你依赖的那个从库真在参与——得挨个登录从库确认rpl_semi_sync_slave_enabled和Rpl_semi_sync_slave_status都为ON
真正难调的从来不是timeout数值，而是让ACK能稳定、低延迟地回来。网络RTT、从库IO压力、TCP栈配置、甚至从库上是否混跑备份流量，这些细节一漏，再大的timeout也只是给降级多留几秒体面。
