ticdc 日志包含大量的 execute dml with error 报错

🪐 TiDB 技术问题 备份&数据迁移
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】4.0
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
cdc 有高延迟，查看日志发现了很多dml error ，不知是否因为下游死锁导致？ 发生问题的时间点也有相同日志。可以跟图对上
【资源配置】
【附件：截图/日志/监控】

BUXvSj6qpJ
BUXvSj6qpJ766×238 47.2 KB

VOzC2Px3FJ
VOzC2Px3FJ998×289 50 KB

[2023/07/05 00:01:05.781 +00:00] [WARN] [mysql.go:854] [“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\n\tgithub.com/pingcap/errors@v0.11.5-0.202011261020
27-b0a155152ca3/errors.go:174\ngithub.com/pingcap/errors.(*Error).GenWithStackByCause\n\tgithub.com/pingcap/errors@v0.11.5-0.20201126102027-b0a155152ca3/normalize.go:279\ngithub.com/pingcap/ticdc/pkg/error
s.WrapError\n\tgithub.com/pingcap/ticdc@/pkg/errors/helper.go:28\ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDMLWithMaxRetries.func2.3\n\tgithub.com/pingcap/ticdc@/cdc/sink/mysql.go:877\ngithub.com
/pingcap/ticdc/cdc/sink.(*Statistics).RecordBatchExecution\n\tgithub.com/pingcap/ticdc@/cdc/sink/statistics.go:99\ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDMLWithMaxRetries.func2\n\tgithub.com/p
ingcap/ticdc@/cdc/sink/mysql.go:865\ngithub.com/pingcap/ticdc/pkg/retry.Run.func1\n\tgithub.com/pingcap/ticdc@/pkg/retry/retry.go:32\ngithub.com/cenkalti/backoff.RetryNotify\n\tgithub.com/cenkalti/backoff@
v2.2.1+incompatible/retry.go:37\ngithub.com/cenkalti/backoff.Retry\n\tgithub.com/cenkalti/backoff@v2.2.1+incompatible/retry.go:24\ngithub.com/pingcap/ticdc/pkg/retry.Run\n\tgithub.com/pingcap/ticdc@/pkg/re
try/retry.go:31\ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDMLWithMaxRetries\n\tgithub.com/pingcap/ticdc@/cdc/sink/mysql.go:857\ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDMLs\n\tgithub.c
om/pingcap/ticdc@/cdc/sink/mysql.go:1016\ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSinkWorker).run.func3\n\tgithub.com/pingcap/ticdc@/cdc/sink/mysql.go:790\ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSinkWor
ker).run\n\tgithub.com/pingcap/ticdc@/cdc/sink/mysql.go:811\ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSink).createSinkWorkers.func1\n\tgithub.com/pingcap/ticdc@/cdc/sink/mysql.go:635\nruntime.goexit\n\trun
time/asm_amd64.s:1357”]

2

下游是 mysql 吧，mysql 会有一个范围锁，会导致出现 lock 的问题，降低 cdc 写下游的并发有利于避免该问题。

3

在尝试获取锁的时候发生了死锁。由于死锁是并发访问数据库时常见的问题，因此需要特别处理。

在处理死锁时，可以考虑以下几点：

  1. 重试事务：在捕获到该错误之后，可以选择在稍后重试事务。在重试事务之前，可以等待一段时间，以便其他事务有足够的时间完成并释放所占用的资源。
  2. 优化查询语句：死锁通常是由于并发访问同一个资源而引起的，因此可以优化查询语句，减少对同一资源的并发访问。例如，可以使用索引来加速查询，减少锁的竞争。
  3. 调整事务隔离级别：事务隔离级别决定了事务之间的可见性和并发性，不同的隔离级别会对死锁的产生和解决产生不同的影响。可以考虑将事务隔离级别调整为更低的级别，以减少死锁的发生。
  4. 减少事务的范围：事务的范围越大，对资源的占用时间就越长，从而增加了死锁的风险。可以尝试将事务的范围缩小，以减少事务之间的竞争。
1 个赞
4

试试cdc限速

5

确认下游数据库是否存在死锁情况。通过检查下游数据库的日志、监控或任何可以提供关于死锁的信息来进行确认。