MySQL报错MY-010635，ER_NDB_BINLOG_REPLY_TO故障远程处理经验分享

那次遇到MySQL报错MY-010635，也就是ER_NDB_BINLOG_REPLY_TO，确实让人头疼，当时是半夜，监控系统突然告警，说一个使用MySQL NDB集群的数据库从库同步中断了，登录到服务器一看，错误日志里刷的就是这个错，这个错误信息大致是说，NDB集群的二进制日志注入线程在等待某个SQL线程的回复时超时了,导致复制中断。

第一步：先稳住，别让问题扩大

遇到这种核心数据库同步停摆的情况，第一反应肯定是紧张，但经验告诉我们，慌没用,我先做了两件事：

1. 确认影响范围：这个从库是专门用于做报表查询的，暂时不影响主库的写入业务，所以还有时间仔细排查,不用急着重启。
2. 检查基本状态：立刻用 SHOW SLAVE STATUS\G 命令查看了从库的详细状态，果然，Slave_IO_Running 是 Yes，但 Slave_SQL_Running 是 No，Last_SQL_Error 就指向了我们看到的那个MY-010635错误,这说明负责执行SQL的线程卡住了。

第二步：根据经验，从最常见的原因入手

根据MySQL官方文档和一些社区案例（比如Percona博客和Stack Overflow上的一些讨论）的提示，这个错误往往不是网络问题（因为IO线程是好的），而是SQL线程在执行某个特定事件时“卡住”了，无法向binlog注入线程发送“我收到了”的确认信号,常见的诱因有几个：

1. 大事务：一个非常大的事务（比如一次性删除或更新几十万条数据）在从库上执行时间过长,导致超时。
2. 表结构冲突：主从库的表结构可能在某些关键时刻出现了不一致，比如主库上某个列被删除了，但从库上还存在,导致应用binlog事件失败。
3. 唯一键冲突或外键约束：主库上成功的数据变更，在从库上可能因为数据略微不一致而违反唯一性约束或外键约束,导致SQL线程挂起。

第三步：深入日志，寻找蛛丝马迹

光看错误代码不够，需要更详细的信息，我仔细翻阅了错误日志发生时间点前后的记录，在MY-010635错误出现之前，我注意到有一条警告信息，提到了一个具体的表名和一个DELETE操作，这给了我一个明确的线索：问题很可能出在对这个表执行某个删除操作的时候。

第四步：尝试性修复与验证

既然锁定了可疑的表和操作，接下来就是尝试恢复同步,标准的处理流程通常是：

1. 跳过错误事件：这是恢复服务最快的方法，但有可能导致数据不一致，我尝试了最常用的方法：先 STOP SLAVE;，然后执行 SET GLOBAL sql_slave_skip_counter = 1; 来跳过一个事件，再 START SLAVE;，但这次不灵了，启动后很快又报同样的错，这说明可能不是一个简单的事件错误,或者后面连续多个事件都有问题。

2. 定位更精确的停止点：既然跳过一个不行，我需要知道更准确的位置，再次查看 SHOW SLAVE STATUS 的输出，记下了当前停止位置的binlog文件和位置（Relay_Master_Log_File 和 Exec_Master_Log_Pos），我联系了负责主库的同事，请他帮忙解析那个时间点前后的binlog内容（使用 mysqlbinlog 工具），通过对比,我们发现确实有一个涉及大量数据删除的事务在那个位置附近。

3. 谨慎处理并最终解决：考虑到这个删除操作是业务上预期的（一个定期的数据归档任务），我们判断从库的数据应该和主库是一致的，只是这个事务本身执行耗时太长触发了超时,我们决定采取一个稍微激进但针对性的措施：

   • 停止从库复制。
   • 手动模拟这个删除操作，因为已经知道了具体的SQL语句，我们直接在从库上执行了它，由于从库是只读的，我们先临时关闭了只读设置 SET GLOBAL read_only = OFF;,执行完删除后再恢复。
   • 执行完毕后，我们使用 CHANGE MASTER TO 命令，将复制位置指向这个巨大事务之后的一个安全点位（这个点位也是通过解析主库binlog确定的）。
   • 重新启动复制 START SLAVE;。

这次，Slave_SQL_Running 和 Slave_IO_Running 都顺利变成了 Yes，Seconds_Behind_Master 的延迟也逐渐降为零,复制恢复了！

事后复盘与经验总结

这次远程处理MY-010635错误,有几个关键点值得分享：

• 日志是关键：不要只看错误代码,错误发生前后的详细日志信息往往包含解决问题的钥匙。
• 理解错误本质：这个错误是“等待回复超时”，所以核心是找出SQL线程为什么“不回复”，问题焦点在SQL线程的执行环节,而不是网络。
• 跳过错误要谨慎：sql_slave_skip_counter 虽好，但不能滥用，盲目跳过可能掩盖更严重的数据不一致问题,最好能明确知道跳过的具体是什么内容。
• 备选方案：如果上述方法都无效，在一些非严格要求的场景下，最后的办法可能是重建从库（从头做一次全量同步），但这耗时很长,应是万不得已的选择。
• 预防优于治疗：事后我们优化了业务上的大数据量操作，建议业务方将其拆分成多个小批次事务执行，避免单个事务过长,也加强了主从库表结构变更的自动化检查和同步流程。

处理MY-010635这类NDB集群相关的复制错误，需要耐心分析日志，结合binlog内容进行精准定位,然后选择对数据一致性影响最小的方案进行操作。