# [Known Issues] 上游 TiDB 大事务导致 TiCDC 同步延迟

## Key Words

TiCDC 延迟，TiCDC OOM，大事务

## Description

TiCDC 同步延迟，checkpoint ts 不推进，TiCDC 内存持续上涨并可能导致 OOM。

## Root Cause

TiCDC 处理大事务时存在瓶颈，即 TiCDC 会拼一个完整事务向下游执行，若某张表的事务过大，TiCDC sorter 和 mounter 处理时会消耗大量内存对 kv event 进行排序和解码，大事务在下游执行通常也比较缓慢，拖慢整体 checkpoint 推进。

## Diagnostic Steps

1. 检查上游是否有大事务：
    * TiDB 日志 BIG_TXN 关键字
    * TiDB 监控 Transaction Write Size Bytes 事务大小
2. 检查 TiCDC 监控 Sink write duration、Sink write rows count 指标，通常在大事务向下游执行期间明显上涨。

## Resolution

v6.1 版本 TiCDC 进行优化，将大事务拆分为小事务，可大幅降低大事务带来的延迟和和内存消耗；从 v6.1.1 版本起，通过配置 sink uri 参数 [transaction-atomicity](https://docs.pingcap.com/zh/tidb/stable/manage-ticdc#sink-uri-%E9%85%8D%E7%BD%AE-mysqltidb)=none 来开启 TiCDC 拆分单表事务功能。

> **注意**

> 1. transaction-atomicity 默认值为 table 时 TiCDC 可以保证单表事务的原子性，当修改该值为 none 时 TiCDC 拆分单表事务将破坏事务的原子性，TiCDC 故障时无法回滚完整的事务，此时下游可能处于某个不一致中间状态，需要等 TiCDC 恢复或 failover 之后再完整向下游同步故障期间的数据，才可以保证数据的一致性。
> 2. 单表事务过大时，可能会遇到单表处理 event 的内存超过 [per-table-memory-quota](https://github.com/pingcap/tiflow/blob/v6.2.0/pkg/config/server_config.go#L177) 限制触发流控，可以通过 tiup 在 cdc 相关配置中添加 per-table-memory-quota 适当调大该参数（v6.2 及之前版本默认 10MiB）。

## Workaround

尽量避免在上游执行大事务，对大事务导致 TiCDC 同步卡住的问题，可以将包含大事务部分的增量数据通过 BR 进行增量恢复，详见文档[操作步骤](https://docs.pingcap.com/zh/tidb/stable/ticdc-faq#ticdc-%E6%94%AF%E6%8C%81%E5%90%8C%E6%AD%A5%E5%A4%A7%E4%BA%8B%E5%8A%A1%E5%90%97%E6%9C%89%E4%BB%80%E4%B9%88%E9%A3%8E%E9%99%A9%E5%90%97)。

## Affected Versions

<v6.1.0