[mysql.go:935] [“execute DMLs with error, retry later”] [error="[CDC:ErrMySQLTxnError]Error 1213: Deadlock found when trying to get lock; try restarting transaction: Error 1213: Deadlock found when trying to get lock; try restarting transaction"
配置采用的ticdc默认设置，
类似的问题怎样处理？
这不先分析下innodb engine status上死锁触发的场景是什么？
在 Mysql 端是否能找到死锁相关的信息？比如那个表，某一行？
然后在看看是什么问题导致了数据同步的死锁？
这个估计是ticdc本身的bug，多个线程同时update同一张表，出现上述错误。
有没有数据来证实你的描述？
这边也好模拟这个场景
现在数据都是生产的数据，用大量的update同一张表，就可以模拟出来
ticdc 处理update 时，有两种策略，你用的哪种？
最好补充下信息，不然这样没办法帮你
tiup cdc cli changefeed create --pd=http://192.168.9.xxxx:2379 --sink-uri=“mysql://tidb_cdc:xxxxx@192.168.9.xxxx:3306/” --changefeed-id=“tidb-replication-task” --sort-engine=“unified”
这个是创建cdc任务执行的命令，你说的处理update的两种策略，在哪查询？谢谢
你采用的如果是默认配置，就是开启的
Old value
Old value 特指在 TiCDC 输出的增量变更日志中的“原始值”。可以通过配置来指定 TiCDC 输出的增量变更日志是否包含“原始值”。
{
“info”: {
“sink-uri”: “mysql://tidb_cdc:xxxx@192.168.9.xxxx:3306/?max-txn-row=20\u0026worker-number=1”,
“opts”: {
“_changefeed_id”: “sink-verify”
},
“create-time”: “2021-12-09T16:12:36.581141775+08:00”,
“start-ts”: 429663861225816065,
“target-ts”: 0,
“admin-job-type”: 0,
“sort-engine”: “unified”,
“sort-dir”: “”,
“config”: {
“case-sensitive”: true,
“enable-old-value”: true,
“force-replicate”: false,
“check-gc-safe-point”: true,
“filter”: {
“rules”: [
“.”
],
“ignore-txn-start-ts”: null
},
“mounter”: {
“worker-num”: 16
},
“sink”: {
“dispatchers”: null,
“protocol”: “default”
},
“cyclic-replication”: {
“enable”: false,
“replica-id”: 0,
“filter-replica-ids”: null,
“id-buckets”: 0,
“sync-ddl”: false
},
“scheduler”: {
“type”: “table-number”,
“polling-time”: -1
},
“consistent”: {
“level”: “none”,
“max-log-size”: 64,
“flush-interval”: 1000,
“storage”: “”
}
}
这是默认的cdc配置信息，请问死锁的问题怎样解决？
你的版本，相关的背景，结构，数据信息，能提供么？
tidb v5.3.0 采用ticdc同步到下游mysql5.7.11 整个库进行同步。
目前的解决方案可以先参考 TiCDC多线程出现死锁：error="[CDC:ErrMySQLTxnError]Error 1213: Deadlock found when trying to get lock 绕过去一下
死锁的问题依然没有解决。work-num线程数改成1
配置文件如下
指定配置文件中涉及的库名、表名是否为大小写敏感
该配置会同时影响 filter 和 sink 相关配置，默认为 true
case-sensitive = true
是否输出 old value，从 v4.0.5 开始支持，从 v5.0 开始默认为 true
enable-old-value = true
[filter]
忽略指定 start_ts 的事务
ignore-txn-start-ts = [429907196957163533,429907196957163535]
过滤器规则
过滤规则语法：https://docs.pingcap.com/zh/tidb/stable/table-filter#表库过滤语法
[mounter]
mounter 线程数，用于解码 TiKV 输出的数据
worker-num = 1
这个问题是 TiCDC 当前行分发规则是按 pk/uk 值不同分发到不同线程导致的。死锁的易出现原因是：TiCDC 为了实现 exactly one 语义将 update 拆成了 delete + replace into，导致 MySQL 在 RC 和 RR 隔离级别下都极易出现重合的 gap lock，导致了死锁。
临时措施：
（1）https://docs.pingcap.com/zh/tidb/stable/manage-ticdc/#sink-uri-配置-mysqltidb ，将 Mysql Sink 的 worker-count 调整成1；（会影响并发，不过考虑到本来就有比较多的死锁，所以还可以接受）
（2）需要下游 MySQL 临时去掉 uk，减少 gap lock；（不影响并发，但业务要自己评估去掉 uk 对查询的影响）
TiCDC 改进方案(ongoing (1)(2) ):
(1) 将和 MySQL 的连接隔离级别调整 rc；
(2) 支持用户自定义的表级分发规则；
(3) 更长远的是：重构 exactly-one 方案，避免分拆 update
1 个赞
你的改的 worker-num 应该是有问题的，mounter 线程数控制的是上游 raw kv 的解码并发，不是到下游 mysql 的并发数，具体链接已经回复在下面，可以先暂时重建下 changefeed 或者 update changefeed 配置。
出现死锁，重试呗。。很频繁吗
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。