# [Known Issues] MySQL 死锁导致 TiCDC 同步延迟

## Key Words

MySQL DeadLock，TiCDC 同步延迟，safe mode，REPEATABLE READ

## Description

TiCDC 同步到下游 MySQL/Aurora 出现同步延迟时，TiCDC 日志看到有 MySQL 死锁报错 "MySQL txn error: Error 1213: Deadlock found when trying to get lock; try restarting transaction"。

## Root Cause

TiCDC 默认开启 [safe mode 模式](https://docs.pingcap.com/zh/tidb/stable/dm-safe-mode#%E5%AE%89%E5%85%A8%E6%A8%A1%E5%BC%8F%E5%8E%9F%E7%90%86)，会将 insert/update 变为 replace into 语句，由于 MySQL gap lock 可能引起 deadlock 并重试，下游写入延迟增加，导致 TiCDC 同步延迟增加。

目前已知触发死锁的情况有以下两种：

情况1：表结构只有主键 pk，replace into 触发了 MySQL RR （REPEATABLE READ）隔离级别下的 gap lock，导致出现 gap lock + insert intension lock 的死锁，详见 issue [#3589](https://github.com/pingcap/tiflow/issues/3589#issuecomment-978805805)。

情况2：表结构同时有主键 pk 和唯一键 uk，replace into 在 uk 上出现了 gap lock + insert intension lock 的死锁，主要原因是 replace 遇到 uk 冲突时会加 X 锁（next key lock），而 replace into 对于 uk 采取标记 delete + insert 的方式，insert 需要加 insert intension lock，具体来说（参考 issue [#3589](https://github.com/pingcap/tiflow/issues/3589#issuecomment-988485558)）

1. 事务1：replace into 发现 uk 列冲突，成功获取 uk 列的 X next key lock
2. 事务2：replace into 发现 uk 列冲突，获取 uk 列的 gap lock 成功，但是获取 record-lock 失败，等待事务1
3. 事务1：执行 uk 上的 insert 操作，发现该位置存在 gap lock，需要先获取相应的 insert intention lock，此时发现事务2持有 gap lock ，等待事务2

## Diagnostic Steps

1. TiCDC 日志有 MySQL 死锁报错 "MySQL txn error: Error 1213: Deadlock found when trying to get lock; try restarting transaction"。

2. MySQL 通过 show engine innodb status 查看死锁信息，触发死锁的 SQL 是 replace into 语句，对于情况2，触发死锁的是对同一条记录的 replace into。

## Resolution

对于情况1：从 v6.0.0 开始，TiCDC 下游 MySQL 连接默认采用 RC 隔离级别 [tiflow #4138](https://github.com/pingcap/tiflow/pull/4138)。

对于情况2：从 v6.1.1 开始，TiCDC 同步非 duplicated events 时关闭 safe mode，减少了死锁发生的概率 [tiflow #5611](https://github.com/pingcap/tiflow/issues/5611)。

## Workaround

将死锁严重的表单独建立 changefeed 并且将 MySQL sink [worker-count](https://docs.pingcap.com/zh/tidb/stable/manage-ticdc#sink-uri-%E9%85%8D%E7%BD%AE-mysqltidb) 设置为 1；对于情况 2，如果业务允许，可以将 uk 删除。

## Affected Versions

<v6.1.1