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

## Issue

TiCDC 的下游目标系统缺少某一张或几张表的数据，且在 TiCDC 监控中的以下两个面板中看到在同一时刻存在两个或两个以上角色为 Owner 的节点。

影响范围 TiCDC 版本：[4.0.0,4.0.11], 5.0.0-RC 集群内其他组件的版本与此问题无关

触发条件 当 TiCDC Server 与 PD 之间链接不稳定时，有概率触发此问题。

## Root Cause

当满足【触发条件】时，ETCD 认为旧 Owner 已经下线，并选举了新 Owner，但是旧 Owner 在某些情况下，并未判断自己是否任期已经结束就直接操作了 ETCD 中的元数据，导致 ETCD 中元数据状态混乱，进而引发某些表没有被监听。

## Diagnostic Steps

N/A

## Resolution

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

如果下游是 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