mysql半同步复制退化为异步需先查主库状态变量rpl_semi_sync_master_off_times是否持续增长，再结合error log中timeout waiting for slave ack等上下文日志及从库io线程状态交叉分析，降级后无新事务则不触发恢复且日志无记录。
错误日志里根本不会直接写“半同步已退化”——它只记录插件加载、超时事件和ACK失败，关键线索藏在时间戳、线程ID和上下文关联中。
查日志前先确认主库是否真在退化
别一上来就翻日志。先连主库执行：SHOW STATUS LIKE 'Rpl_semi_sync_master_off_times';。如果这个值在持续增长，再查日志才有意义；如果一直是 0，说明压根没触发退化，日志里也不会有相关记录。
-
Rpl_semi_sync_master_off_times每涨 1，代表主库主动关闭半同步一次，对应日志里至少一条Timeout waiting for slave ACK或类似提示 -
Rpl_semi_sync_master_wait_timeouts飙升但Rpl_semi_sync_master_off_times不涨，说明单次事务重试多次失败，但还没到“关插件”阈值，日志里可能只有警告，没 ERROR 级别条目 - 日志路径必须是主库的 error log，不是从库的——从库日志里找不到退化依据
grep 关键字要带时间窗口和线程上下文
半同步超时日志不是孤立出现的，它往往和 slave_io_thread 卡住、net_read 超时或 TCP 重传日志挨着出现。盲目 grep "semi" 容易漏掉真正诱因。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 用
grep -A 5 -B 5 "Timeout waiting for slave ACK" /var/log/mysql/error.log，前后各抓 5 行，看是否紧跟着Got timeout reading communication packets或Aborted connection - 重点匹配
thread_id=.*ack_receiver—— 主库接收 ACK 的专用线程 ID，它的卡顿或退出直接导致退化 - 如果看到
Got an error reading communication packets后紧跟Timeout waiting for slave ACK，基本锁定是网络层丢包或从库 TCP 接收队列满（ss -i查rcv_space是否长期接近rmem）
区分日志里的“超时”是网络延迟还是从库写 relay log 慢
同一句 Timeout waiting for slave ACK 可能对应两种完全不同的根因：一种是 ACK 包根本没发出来（从库卡在写 relay log），另一种是 ACK 发了但主库没收到（中间网络抖动）。日志本身不区分，得结合其他指标交叉判断。
- 如果日志里
Timeout waiting for slave ACK出现前后，从库SHOW PROCESSLIST中Slave_IO_Running: Yes但状态长期卡在Waiting for master to send event，说明 ACK 没发出，问题在从库 IO 线程或磁盘刷盘（检查sync_relay_log=1和磁盘 I/O util） - 如果从库
State是Queueing master event to the relay log或Reading event from the relay log，但主库日志仍报超时，说明 ACK 已发、主库没收到，该查主从间 UDP 丢包率（iperf -c 从库IP -t 30 -u）和netstat -s | grep "packet reassemblies failed" - 日志里若反复出现
semi-sync: slave io thread is not running，说明从库 IO 线程异常退出过，不是超时问题，而是复制链路本身中断
日志里没有报错，但 Rpl_semi_sync_master_status 仍是 OFF
这种情况最常见于降级后没新事务触发恢复。日志安静如鸡，但半同步实际已失效——因为 MySQL 不会在空闲时写日志告诉你“我还在异步模式”。
- 查日志最后一条写入时间，如果距今超过 10 分钟，且
Rpl_semi_sync_master_status = OFF，大概率是主库没写入，降级后一直卡着 - 此时日志里找不到任何半同步相关条目，必须靠监控驱动动作：一旦发现
Rpl_semi_sync_master_status = OFF，立刻执行一个轻量事务，比如INSERT INTO heartbeat (ts) VALUES (NOW());，再查日志，你会看到新的Timeout waiting for slave ACK或成功恢复的Semi-sync enabled记录 - 别依赖日志自动“补全”，MySQL 的半同步恢复机制是被动触发的，日志只忠实地记录它干过的每一件事，不干的事它绝不会预告
日志只是证据链的一环，单独看容易误判。真正要盯住的，是 Rpl_semi_sync_master_off_times 的变化节奏、从库 Seconds_Behind_Master 是否同步上涨、以及主从间真实 RTT 的 P95 值——这三者对齐了，日志里的每一行才能读出准确含义。
