rpl_semi_sync_master_status在on/off间跳变是因为等待从库ack超时，并非插件故障；根本原因是rpl_semi_sync_master_timeout设置不当（如100ms），与实际rtt峰值、tcp队列积压不匹配，导致频繁降级为异步。
为什么Rpl_semi_sync_master_status在ON/OFF间跳变
主库的Rpl_semi_sync_master_status从ON变成OFF，不是插件崩溃或配置失效，而是它在明确告诉你：至少一次等待从库ACK超时了。半同步机制本身不追求“永不降级”，只在能稳住的时候才坚持；一旦rpl_semi_sync_master_timeout设得太紧（比如100），而实际网络RTT峰值已达3–5ms、再叠加TCP队列积压，就必然触发降级。
怎么查是不是网络层丢包或延迟抖动
不能只看ping或traceroute——它们用ICMP，而MySQL半同步走的是TCP小包（ACK）。真实问题常藏在TCP接收队列里：
- 登录从库，检查
net.ipv4.tcp_rmem：如果第二或第三个值（如4096 131072 6291456）过小，内核可能直接丢弃ACK小包，主库收不到，只能超时 - 在主库抓包验证：
tcpdump -i any 'host and port 3306 and tcp[13] & 16 != 0'，观察是否有大量重复ACK或长时间无响应 - 对比
Rpl_semi_sync_master_no_times和Rpl_semi_sync_master_off_times：若两者每小时增长几十次，说明不是偶发抖动，而是网络或从库IO已持续承压
如何验证ACK到底是谁发的、有没有被正确处理
Rpl_semi_sync_master_status=ON只表示“至少有一个从库连上了且声称支持半同步”，不代表你依赖的那个从库真在参与。必须逐个确认：
- 查主库当前有几个半同步客户端：
SHOW STATUS LIKE 'Rpl_semi_sync_master_clients'; - 挨个登录每个从库，执行
SELECT @@rpl_semi_sync_slave_enabled, @@Rpl_semi_sync_slave_status;，两个都必须是ON - 重点看从库的
SHOW PROCESSLIST中Slave_IO_Running: Yes但Seconds_Behind_Master持续上涨——这说明relay log写入已滞后，ACK发出前数据还没落盘，形同虚设
rpl_semi_sync_master_timeout该设多少才合理
它不是越长越安全，而是要落在真实网络与负载的波动区间内。设错会放大风险：
- 局域网（RTT稳定在0.5–2ms）：
SET GLOBAL rpl_semi_sync_master_timeout = 1000;是起点，覆盖99%尖峰抖动足够 - 跨机房或高负载（RTT偶发飙到15ms+）：
3000～5000可试，但别碰10000（默认值），否则单事务可能卡10秒 - 绝对不要设低于
500：哪怕ping延迟只有0.3ms，UDP小包丢包率>0.1%时，100超时也几乎必降级 - 改完立即生效：
SET GLOBAL rpl_semi_sync_master_timeout = 3000;，无需重启
真正难的不是调timeout，而是确认ACK路径上每一环——主库发得出去、网络传得稳、从库收得到、内核不丢包、SQL线程来得及落盘。漏掉任意一环，调再大的timeout也只是把问题拖得更隐蔽。
