没开着

它就不应该打开 而且我测试环境是5.7.44 生产环境是25 ，生产环境做了很多DM任务，都没事 更高版本的应该更没有问题才对。

在上游，

处置过程： 1、把TIDB中相关表多的列都删除，使得上下游表结构完全相同 2、由于同步任务处于pause状态 ，所以直接 resume-task ，然后查询任务，问题没有得到解决。 3、停掉任务，重新开启任务 同时加上–remove-meta 4、查询状态，问题已被解决。

好的，我试试

是的 ，我的pos点位值时，没有新加列，是 59个列，当时tidb是61个，所以执行的 from source 操作 ，执行后，无效。

社区版5.7.25

最直接的，最快捷的是调整监控数据保留天数

看下top SQL 和慢SQL ,按对应时间查看，比较好排查

原来就是远程分析，后来不行才改为本地模式

我是整表更新的 。没有where条件，应该不存在漏掉的情况 [image] [image] [image] 更新后 [image] 启动任务 [image] 任务出现错误后 [image]

感觉这种模式适用于开启GITMOD的情况，我的没开启，所以都是 0 我看了半天，其实就是把binlog拷贝过来，本身log中的pos位置已经不对了（int32溢出）。你就算再执行也不对

已经按那个做了，还是存在错误。

{ “result”: true, “msg”: “”, “sources”: [ { “result”: true, “msg”: “”, “sourceStatus”: { “source”: “mysql50133_3306”, “worker”: “dm-192.168.55.25-8264”, “result”: null, “relayStatus”: { “masterBinlog”: “(mysql57-bin.002172, 351878096)”, “masterBinlogGtid”: “”, “relaySubDir”: “75f42d7f-…

后来理解明白了，先开启了relay log ，然后 关闭了 DM Work ，然后一步步做，还是报错

按照这个方案做了 现在还是有错误 ，具体如下 “result”: true, “msg”: “”, “sources”: [ { “result”: true, “msg”: “”, “sourceStatus”: { “source”: “mysql50133_3306”, “worker”: “dm-192.168.55.25-8264”, “result”: null, “relayStatus”: { “masterBinlog”: “(mysql57-bin.002172, 243054667)”, “masterBinlogGtid”: “”, “re…

上一次同样问题，刚经过了3天时间重做了，现在又出现了 。做不起了。

找了半天，没有找到relay log ，好像我没有开启

这个是生产环境，不能跳过文件，否则数据有丢失