# 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报错信息   
![](https://support.huaweicloud.com/dataartsstudio_faq/zh-cn_image_0000002358632408.png "点击放大")
#### 原因分析
Migration作业尝试从MySQL数据库获取指定binlog文件发现binlog文件已经被清理。
实时抽取MySQL数据需要在MySQL数据库侧开启binlog日志，**未开启binlog日志或binlog日志保留时间过短** 都会导致binlog日志意外丢失，导致作业失败。请参考[MySQL源端数据源约束](https://support.huaweicloud.com/usermanual-dataartsstudio/dataartsstudio_01_7762.html#section0)排查是否有其他权限问题。
#### 解决方案
- 场景一：主键表补数
  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报错信息   
       ![](https://support.huaweicloud.com/dataartsstudio_faq/zh-cn_image_0000002392435385.png "点击放大")
       ![](https://support.huaweicloud.com/dataartsstudio_faq/public_sys-resources/note_3.0-zh-cn.png)
       以上样例只介绍方法，请忽略样例中时间值的合理性。
       图3从监控信息中查看作业已消费位点   
       ![](https://support.huaweicloud.com/dataartsstudio_faq/zh-cn_image_0000002392320021.png "点击放大")
       
       
       
  
  
  
  3. 使用离线作业补数。
  
  
  用户通过业务时间字段（如create_time/update_time）过滤出丢失数据，创建数据集成离线作业或者CDM作业将丢失的数据迁移到目的端。
  ![](https://support.huaweicloud.com/dataartsstudio_faq/public_sys-resources/note_3.0-zh-cn.png)
  离线补数的过程中需要停止实时作业。
  
- 场景二：非主键表或没有业务时间字段 用户可以根据业务情况，使用其他字段过滤丢失数据进行离线补数。
  在评估业务影响后，必要时可以做全表数据重迁。