# [Critical bug] TiCDC 同步异常停止且无法恢复的 BUG

## Issue

### Bug 现象

   1. Changefeed 报错：ErrSchemaStorageTableMiss/ErrSnapshotSchemaExists/ErrSnapshotSchemaNotFound/ErrSnapshotTableExists

   2. 通过 cdc cli changefeed resume 命令无法恢复同步任务

   3. Changefeed 状态在 error 和 normal 之间周期性的切换

   4. 同步进度停滞，checkpoint ts 自第一次报错后始终没有推进

### 触发条件

当 TiCDC 的下游是 TiDB/MySQL 时，TiCDC 向下游执行 DDL 过程中遇到任何错误，都会触发这个 BUG；当 TiCDC 的下游是 Kafka 时，TiCDC 将 DDL Event 发送到 Kafka 的过程中遇到任何错误，都会触发这个 BUG。

### 易发场景

该问题在 TiCDC 上游集群频繁运行 DDL 场景时有一定概率会被触发，触发概率与 DDL 执行频率正相关。通常情况下，执行 DDL 的频率超过 30 个 /min 并持续 20 分钟左右，会触发该问题。

### Bug 引发的后果

出现问题的 Changefeed 中断且无法恢复，对应的同步任务中断。

### Root Cause

N/A

## Diagnostic Steps

## Resolution

将 TiCDC 版本升级到 v5.1.2 及其以上的版本。

## Workaround

* 前置检查工作 检查 GC safe time，确保 GC safe time 在出现问题的 changefeed 的 checkpoint ts 之前，操作如下： 1.执行 select * from mysql.tidb where VARIABLE_NAME = 'tikv_gc_safe_point'; 查看 GC safe time 值。 2.执行 cdc cli changefeed list 查看出现问题的 changefeed 的 checkpoint 值。 3.确保 GC safe time 早于 checkpoint（如果 GC safe time 等于 checkpoint，则不可以使用 workaround 方法)。

    * 具体操作

        1. 暂时禁止 GC 推进：执行 SQL update mysql.tidb set variable_value='720h' where variable_name='tikv_gc_life_time';。

        2. 删除出现问题的 changefeed，记此时 checkpoint ts 为 ts1。

        3. 重建 changefeed，设置 startts 为 ts1 - 1。

        4. 恢复 GC 推进：执行 SQL update mysql.tidb set variable_value='?' where variable_name='tikv_gc_life_time';将 ? 替换为原有的 gc life time。

> **注意**
>
> 1. 在近期频繁 DDL 的场景中，不建议使用上述 workaround。每一次做 DDL 都有几率触发发该 BUG，进行 workaround 绕过 BUG 后，有可能后续做 DDL 操作会再次触发 BUG。
> 2. workaround 操作涉及手动操作 changefeed，如果 changefeed 数量比较多，操作会比较繁琐。
> 3. 删除 changefeed 时注意保留原 changefeed 配置文件，以便后续重建。
> 4. 操作比较复杂，建议直接走 On-call 流程以获得研发支持。