MySQL报错修复 远程数据库维护 MySQL Error number:MY-011150;Symbol:ER_SEMISYNC_MOVE_BACK_WAIT_POS;SQLSTATE:HY000 故障处理

MySQL报错修复手记：ER_SEMISYNC_MOVE_BACK_WAIT_POS故障处理 🛠️

深夜告警：半同步复制异常

凌晨2:15，手机突然疯狂震动 📳——监控系统发来警报："主从同步延迟超过阈值！" 揉着惺忪睡眼连上服务器，看到满屏的红色错误日志：

[ERROR] [MY-011150] [Repl] Semi-sync master failed on net_flush() before waiting for slave reply.
Error_code: MY-011150; Symbol: ER_SEMISYNC_MOVE_BACK_WAIT_POS; 
SQLSTATE: HY000

作为一个常年与MySQL打交道的DBA,我知道今晚的睡眠又要泡汤了 😴，这个ER_SEMISYNC_MOVE_BACK_WAIT_POS错误是半同步复制中的"老熟人"，但每次出现都可能隐藏着不同的问题。

故障初诊：半同步复制原理

先快速回顾下半同步复制的工作机制 🔄：

1. 主库执行事务后,将事务发送给至少一个从库
2. 从库收到后写入relay log并返回ACK
3. 主库收到ACK后才认为事务提交成功

而ER_SEMISYNC_MOVE_BACK_WAIT_POS错误通常发生在主库等待从库ACK时网络出现问题,导致主库不得不回退等待位置，就像快递员送包裹时收件人突然失联 📦❌

详细排查步骤

第一步：检查基础网络

ping slave-db01
traceroute slave-db01
netstat -an | grep 3306

网络延迟突然从平时的1ms飙升到350ms！原来是IDC网络设备在进行夜间维护 🚧

第二步：验证半同步状态

SHOW STATUS LIKE 'Rpl_semi_sync%';

关键指标：

• Rpl_semi_sync_master_status: OFF （主库半同步已降级为异步）
• Rpl_semi_sync_master_no_tx: 23 （有23个事务未能半同步）
• Rpl_semi_sync_master_timefunc_failures: 5 （超时失败5次）

第三步：分析错误日志上下文

grep -A 20 -B 20 "ER_SEMISYNC_MOVE_BACK_WAIT_POS" /var/log/mysql/error.log

发现伴随出现的还有：

[Note] Timeout waiting for reply of binlog (file: mysql-bin.000123, pos: 4578923)

解决方案实录

临时应对措施

SET GLOBAL rpl_semi_sync_master_timeout = 10000; -- 将超时从默认10秒改为10秒
SET GLOBAL rpl_semi_sync_master_wait_for_slave_count = 1; -- 只需1个从库确认

永久修复方案

1. 联系网络团队修复跨机柜光纤抖动问题 🌐
2. 调整从库参数：

   [mysqld]
   slave_parallel_workers = 8
   slave_preserve_commit_order = ON

3. 主库优化：

   SET GLOBAL sync_binlog = 1;
   SET GLOBAL innodb_flush_log_at_trx_commit = 1;

监控增强

新增告警规则：

• 半同步降级持续时间 > 30s
• 主从延迟 > 100MB
• 网络延迟 > 50ms

经验总结 💡

1. 超时时间不是越长越好：设置过长的rpl_semi_sync_master_timeout会导致事务堆积
2. 网络是隐形杀手：75%的半同步问题最终都是网络问题
3. 降级机制是把双刃剑：自动降级为异步能保业务，但可能丢失数据

凌晨4:30，看着监控大盘恢复全绿，我泡了杯咖啡 ☕，每次故障都是最好的学习机会，这次又往我的DBA经验包里塞了个新案例，记得定期检查半同步复制的健康度，别等报警响了才处理！