MySQL5.7-->MySQL5.7增量同步根据时间戳回溯位点任务重启异常

[尘土]

异常信息：
com.clougence.cloudcanal.mysql.worker.reader.vendor.parse.exception.CanalParseException: apply failed
Caused by: com.clougence.cloudcanal.base.task.CanalException: metadata history findByTimestamp failed.destination:canal715707qbhu8_INCREMENT,msg:CanalException: ,response msg:Fetch task rsocket request’s async result from future timeout. Current timeout time is 5000. Route name is mysqlFindHistoryMetadataByTimestamp, requestId is ebb58c9c-c37b-11ec-9f50-7b4d7f4b6d9d
Caused by: com.clougence.cloudcanal.base.task.CanalException: ,response msg:Fetch task rsocket request’s async result from future timeout. Current timeout time is 5000. Route name is mysqlFindHistoryMetadataByTimestamp, requestId is ebb58c9c-c37b-11ec-9f50-7b4d7f4b6d9d

[junyu-cloudcanal]

@尘土 被你说对了，这个确实会放进去。。。也是已知问题。我们后续对应的优化措施是：如果不是全库同步，过滤掉create db ，drop db,create table,drop table等

[尘土]

@junyu-cloudcanal
因为数据源有创建临时表的逻辑，因此meta_history中有大量create table, drop table和trucate语句而不是对表进行字段的增删改。请问这三类ddl可以在meta_history表中直接清除吗？会不会影响回溯？

[zycgit]

@尘土 可以参考帖子里面提到的方法清理一下，你也可以考虑关注一下任务日志，有可能是任务报错自动重启了导致的。

[尘土]

@junyu-cloudcanal
请问meta_history表的数据量只会在任务重启时有影响吗？我一个正常运行的增量同步任务，为什么在开启两个小时后，运行期间也报了同样的错误？我查了一下元数据库，这个任务下确实有很多ddl语句。

[junyu-cloudcanal]

@尘土
cloudcanal-mysql 元数据库里面，有一个 meta_history 表，这个表主要记录任务的ddl 语句，如果任务ddl语句非常多，可能导致任务重启的时候获取ddl 变更历史出错。

建议：

1. 登陆 cloudcanal 元数据库，参考这个帖子：https://www.askcug.com/topic/350 .
2. 查询meta_history 表中相关任务的ddl历史，识别下是否有增删改字段的ddl.
3. 清理掉没有增删改字段的其他ddl.
4. 重启任务.