# [Critical bug] TiCDC的两个问题可能导致数据丢失 1:2

## Description

TiCDC的下游目标系统从一个或多个表中丢失了一些数据，而丢失的数据是在上游TiDB的一个或多个时间段内连续写入的某段数据。

## Root Cause

当 TiCDC Server 进程退出或 TiCDC Server 与 PD 之间链接不稳定时，如果发生 TiCDC Capture 之间的表调度，并且在调度完成前，TiCDC owner 发生切换，则可能触发此问题。

TiCDC 的下游目标系统缺少某一张或几张表的部分数据，且丢失的数据在上游 TiDB 是一个或多个时间段内连续写入的某段数据。

## Diagnostic Steps

在调度过程中，一个表被从源Capture调度到目标Capture。在Owner对被调度的表的元信息处理中存在一个漏洞，导致目标Capture中调度表的开始tso大于源Capture中调度表的检查点tso，当[触发条件]被满足时。因此，在[检查点tso，开始tso]之间有提交tso的事务被丢失。

## Resolution

1. 升级 TiCDC 版本到 4.0.12 及以上，或 5.0.0 及以上

2. 如果下游是 TiDB 或其他支持 MySQL 协议数据库(MySQL/Aurora/MariaDB)，可以通过 sync_diff_spector 检查主备集群的数据一致性；同步到 Kafka 的业务，需要用户根据自身业务特点进行数据一致性检查。

对于要恢复已经丢失的数据的情况，可以采用以下方案恢复丢失的数据：

* 如果上游 GC 尚未删除掉下游缺失的数据，可以删除掉丢失数据的 changefeed，以丢失数据时间前的时间点作为 start-ts 重建 changefeed。

* 如果下游是 TiDB 或其他支持 MySQL 协议的数据库：

    * 采用 sync_diff_inspector 通过对比上下游数据差异来恢复下游丢失的数据。

    * br/lightning 重建全量数据后接 TiCDC 增量同步。

## Workaround

N/A

## Affect Version(optional)

TiCDC 版本：v4.0.0~v4.0.11,v5.0.0-RC
注意：集群内其他组件的版本与此问题无关