MySQL增量同步过程中报错，错误信息包含“The connector is trying to read binlog starting at Struct xxx but this is no longer available on the server”怎么办？

问题描述

增量同步MySQL数据过程中或者暂停作业一段时间后恢复作业，作业出现异常，报错关键字“The connector is trying to read binlog starting at Struct 【xxx】 but this is no longer available on the server”，【xxx】中包含具体的binlog位点信息。taskmanager与jobmanager日志中均可看到报错日志。

图1 报错信息

原因分析

Migration作业尝试从MySQL数据库获取指定binlog文件发现binlog文件已经被清理。

实时抽取MySQL数据需要在MySQL数据库侧开启binlog日志，未开启binlog日志或binlog日志保留时间过短都会导致binlog日志意外丢失，导致作业失败。请参考MySQL源端数据源约束排查是否有其他权限问题。

解决方案

• 场景一：主键表补数
  1. 用户评估业务影响后，应该第一时间停止作业、增量重新启动作业，启动位点尽可能设置早一点，避免增量数据进一步丢失，做到及时止损。
  2. 评估丢数范围。
     报错出现时，意味着binlog数据已经丢失，无法通过实时将数据补回，需要核查丢数范围后，通过离线（JDBC）方式将数据补充到目的端数据库。

     • 用户可以根据业务情况评估补数范围。
     • 用户也可以通过以下方式评估相对准确的丢数范围。

       丢数的起始时间为报错日志中的ts_ms时间戳，以图2中的报错信息为例，ts_ms=1750230644428=2025-06-18 15:10:44，补数的开始时间必须早于2025-06-18 15:10:44这个时间点。

       丢数的结束时间可以参考作业重新启动后的消费位点，如图3中已消费位点时间为1752071512000=2025-07-09 22:31:52，补数的结束时间应该晚于2025-07-09 22:31:52这个时间点较为保险。精确的丢数结束时间可以查看重启后作业的taskmanager日志，搜索“binlog offset”关键字，查看第一个checkpoint对应的ts_sec。

       图2 报错信息
       
       

       以上样例只介绍方法，请忽略样例中时间值的合理性。

       图3 从监控信息中查看作业已消费位点
       

  3. 使用离线作业补数。

  用户通过业务时间字段（如create_time/update_time）过滤出丢失数据，创建数据集成离线作业或者CDM作业将丢数数据迁移到目的端。

  

  离线补数的过程中需要停止实时作业。

• 场景二：非主键表或没有业务时间字段

  用户可以根据业务情况，使用其他字段过滤丢失数据进行离线补数。

  在评估业务影响后，必要时可以做全表数据重迁。