好的，感觉6.1版本不是很稳定啊，已经好几个问题了

TiDB限制我已经调到120MB了，同步的数据只有7兆多，不会超过限制的；降级到5.4.1之后，同步就正常了

500多张表；怀疑是DM6.1内部做了txn-entry-size-limit限制，直接返回了，还没有到达TiDB执行

DM版本回退到v5.4.1后，同步恢复正常。

mark一下：https://github.com/pingcap/tiflow/issues/6133

-rw-r–r-- 1 admin grpcaocao 0 2022-06-28 14:46:58 dm-worker_stderr.log -rw-r–r-- 1 admin grpcaocao 4.9K 2022-06-30 11:17:53 dm-worker_stdout.log [admin@tidb-cdc01 log]$ cat dm-worker_stdout.log [2022/06/29 05:58:23.080 +08:00] [INFO] [info.go:49] [“Welcome to TiDB-Lightning”] [component=“ddl …

下游有写入，只是不知道是从头开始导入，还是接着之前的导入；而且重新start-task后，到真正向下游写数据，需要等好久（7～8分钟）

goroutine.txt (125.0 KB)

好的，多谢，我们先把tidb的wait_timeout改为0

下游tidb是通过SLB连接的，用的默认的配置： [image]

目前已经解决了，把上游wait_timeout（默认3600s）改大了就好了；是连接超时断开了导致，建议加个重连机制，要不然拉取超大表数据的时候，会因为时间太久（超过3600s）,再获取下一张表结构的时候就会有异常了，重拉的时间成本太大了。 异常日志被我清掉了，拿不到了，不好意思

恢复dump一段时间后又出现异常退出，并且paused duration明显感觉不对 [2022/05/26 15:52:13.076 +08:00] [INFO] [collector.go:203] [“backup failed summary”] [task=dm-rds_master] [unit=dump] [total-ranges=0] [ranges-succeed=0] [ranges-failed=0] [2022/05/26 15:52:13.095 +08:00] [INFO] [writer.go:77] [“context has been done, th…

kill不掉的，执行了kill tidb 94805后，sql还在，后面重启才没了

没有啊，这个表是空表，你看processlsit都执行了6700多秒了

看我截图，没有正在运行的job_id

job_id都没有，这个命令用不了

2v6

500多张表，我觉得磁盘写日志对同步影响不会这么大，估计是其他问题导致同步异常

这个删除操作后面，是个批量插入的操作，估计有十几兆。 这个大事务处理的问题，是5.4版本首次出现，还是以前版本也有这个问题？