非常感谢
这个问题是由于 cdc 到 mysql 网络不稳定导致 mysql 连接卡住，进而卡住整个 cdc 进程，相关的 bug fix 流程可以在下面的 issue 追踪：
https://github.com/pingcap/ticdc/issues/1275
明白了
相关 bug 在 ticdc 会尽快修复；
该场景下引起的直接原因是下游没有 mediamz 这个库 [error="[CDC:ErrMySQLTxnError]Error 1049: Unknown database 'mediamz'"]
请确保在 ticdc 开始同步的 start-ts 时间点上下游的表结构和数据是一致的
对，这个问题我也很奇怪，为什么会不同步库结构信息，后来我把下游mysql创建了库和所有表结构后，现在可以同步数据了，另外还有个奇怪的问题就是同步数据较慢，同步了一个晚上，数据还没有全部同步完成。
有两张表，238w和2000w，到目前也才完成153w和378w数据，还有其他的表还没开始同步数据，表信息是空的。
查日志有个错误，不明白是什么原因引起的报错？
[2021/01/05 20:41:20.634 +08:00] [WARN] [mysql.go:781] [“execute DMLs with error, retry later”] [error="[CDC:ErrMySQLTxnError]Error 1213: Deadlock found when trying to get lock; try restarting transaction"] [errorVerbose="[CDC:ErrMySQLTxnError]Error 1213: Deadlock found when trying to get lock; try restarting transaction\ngithub.com/pingcap/errors.AddStack\
\tgithub.com/pingcap/errors@v0.11.5-0.20200917111840-a15ef68f753d/errors.go:174\
github.com/pingcap/errors.(*Error).GenWithStackByCause\
\tgithub.com/pingcap/errors@v0.11.5-0.20200917111840-a15ef68f753d/terror_error.go:348\
github.com/pingcap/ticdc/pkg/errors.WrapError\
\tgithub.com/pingcap/ticdc@/pkg/errors/helper.go:28\
github.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDMLWithMaxRetries.func2.3\
\tgithub.com/pingcap/ticdc@/cdc/sink/mysql.go:801\
github.com/pingcap/ticdc/cdc/sink.(*Statistics).RecordBatchExecution\
\tgithub.com/pingcap/ticdc@/cdc/sink/statistics.go:91\
github.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDMLWithMaxRetries.func2\
\tgithub.com/pingcap/ticdc@/cdc/sink/mysql.go:792\
github.com/pingcap/ticdc/pkg/retry.Run.func1\
\tgithub.com/pingcap/ticdc@/pkg/retry/retry.go:31\
github.com/cenkalti/backoff.RetryNotify\
\tgithub.com/cenkalti/backoff@v2.2.1+incompatible/retry.go:37\
github.com/cenkalti/backoff.Retry\
\tgithub.com/cenkalti/backoff@v2.2.1+incompatible/retry.go:24\
github.com/pingcap/ticdc/pkg/retry.Run\
\tgithub.com/pingcap/ticdc@/pkg/retry/retry.go:30\
github.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDMLWithMaxRetries\
\tgithub.com/pingcap/ticdc@/cdc/sink/mysql.go:784\
github.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDMLs\
\tgithub.com/pingcap/ticdc@/cdc/sink/mysql.go:937\
github.com/pingcap/ticdc/cdc/sink.(*mysqlSinkWorker).run.func2\
\tgithub.com/pingcap/ticdc@/cdc/sink/mysql.go:723\
github.com/pingcap/ticdc/cdc/sink.(*mysqlSinkWorker).run\
\tgithub.com/pingcap/ticdc@/cdc/sink/mysql.go:746\
github.com/pingcap/ticdc/cdc/sink.(*mysqlSink).createSinkWorkers.func1\
\tgithub.com/pingcap/ticdc@/cdc/sink/mysql.go:592\
runtime.goexit\
\truntime/asm_amd64.s:1357"]
作为增量同步工具，这个行为是预期的吧，不会像 dm 一样有个 dump load 的过程。
这个应该是同步慢，建议开新帖我们跟下，别跟这个问题混淆。
从提供的 log 看是遇到死锁了。看下 mysql 是不是也有死锁存在
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。