From 736ff16232e5ce294212bdf8f4c5310721a354b0 Mon Sep 17 00:00:00 2001 From: lidezhu Date: Sat, 9 Aug 2025 19:41:53 +0800 Subject: [PATCH 01/10] improve description about ticdc compatibility --- ticdc/ticdc-faq.md | 18 ++++++++++++------ .../tidb-lightning-physical-import-mode.md | 4 +--- 2 files changed, 13 insertions(+), 9 deletions(-) diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 556fe574ecb7..4a464ca6b478 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -284,7 +284,7 @@ Open protocol 的输出中 type = 6 即为 null,比如: * 如果只存在 `"d"` 字段则为 `DELETE` 事件 更多信息请参考 [Open protocol Row Changed Event 格式定义](/ticdc/ticdc-open-protocol.md#row-changed-event)。 - + ## TiCDC 占用多少 PD 的存储空间? 在使用 TiCDC 的过程中,你可能会遇到 `etcdserver: mvcc: database space exceeded` 错误,该错误主要与 TiCDC 使用 PD 内部的 etcd 来存储元数据的机制相关。 @@ -360,22 +360,28 @@ TiCDC 提供至少一次的数据同步保证,当下游有重复数据时, TiCDC 需要磁盘是为了缓冲上游写入高峰时下游消费不及时堆积的数据。TiCDC 正常运行期间都需要写入磁盘,但这通常不是同步吞吐和同步延时的瓶颈,写磁盘对延时影响在百毫秒内。TiCDC 也利用了内存来提升加速读取磁盘中的数据,以提升同步性能。 -## 为什么在上游使用了 TiDB Lightning 物理导入模式和 BR 恢复了数据之后,TiCDC 同步会出现卡顿甚至卡住? +## TiDB Lightning 物理导入模式与 TiCDC 的兼容性存在哪些限制? -目前 TiCDC 尚未完全适配 TiDB Lightning [物理导入模式 (Physical Import Mode)](/tidb-lightning/tidb-lightning-physical-import-mode.md) 和 BR,请避免在使用 TiCDC 同步的表上使用 TiDB Lightning 物理导入模式和 BR。否则,可能会出现未知的错误,例如 TiCDC 同步卡住、同步延迟大幅增加、或者同步数据丢失。 +TiDB Lightning [物理导入模式 (Physical Import Mode)](/tidb-lightning/tidb-lightning-physical-import-mode.md) 是直接将数据生成为 SST 文件并导入 TiKV 集群。由于这种导入方式不涉及常规的数据写入流程,因此不会产生 change log 记录。在大多数情况下,changefeed 无法观察到这部分数据的变更。只有在 changefeed 初始化阶段,或者 region 发生变更(如 split/merge/leader 迁移等)触发增量扫描时,才有可能看到这部分数据,因此 changefeed 并不保证能够完整捕获通过 TiDB Lightning 物理导入模式导入的数据。 -如果有某些使用 TiCDC 同步的表需要使用 TiDB Lightning 物理导入模式或者 BR 恢复数据,可以这么做: +如果 TiDB Lightning 物理导入模式操作的表与 changefeed 监听的表存在重叠,可能由于数据捕获不完整发生各种未知的错误,例如 changefeed 同步卡住,上下游数据不一致等。如需对 TiCDC 同步的表需要使用 TiDB Lightning 物理导入模式,可以按照以下步骤操作 1. 删除涉及这些表的 TiCDC 同步任务。 -2. 使用 TiDB Lightning 物理导入模式或 BR 在 TiCDC 的上游集群和下游集群分别恢复数据。 +2. 使用 TiDB Lightning 物理导入模式在 TiCDC 的上游集群和下游集群分别恢复数据。 -3. 恢复完成并检查了上下游集群对应表的数据一致性之后,使用上游备份的时间点 (TSO) 作为 TiCDC 同步任务的 `start-ts`,创建新的 TiCDC 同步任务,进行增量同步。例如,假设上游集群的 BR 备份的 snapshot 时间点为 `431434047157698561`,那么可以使用以下命令创建新的 TiCDC 同步任务: +3. 恢复完成并检查了上下游集群对应表的数据一致性之后,使用TiDB Lightning 物理导入模式完成后的时间点 (TSO) 作为 TiCDC 同步任务的 `start-ts`,创建新的 TiCDC 同步任务,进行增量同步。 ```shell cdc cli changefeed create -c "upstream-to-downstream-some-tables" --start-ts=431434047157698561 --sink-uri="mysql://root@127.0.0.1:4000? time-zone=" ``` +如果可以确认 TiDB Lightning 物理导入模式操作的表与 changefeed 监听的表不存在重叠关系,可以将 [TiDB Lightning 配置文件](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-任务配置) 的 `check-requirements` 设置为 false,强制执行数据导入操作。 + +## BR(Backup & Restore) 和 TiCDC 的兼容性存在哪些限制? + +BR(Backup & Restore)工具也是直接将数据生成为 SST 文件并导入 TiKV 集群,如上一节所述,changefeed 并不保证能够完整捕获通过这类方式导入的数据。对于 v8.2.0 之前(不包括 v8.2.0)的版本,如果集群上已存在 changefeed 任务,BR 将拒绝创建恢复任务。对于 v8.2.0 及之后的版本,仅当 BR 恢复数据的 backupTs 小于集群上所有 changefeed 的 checkpointTs 时,才允许创建恢复任务。 + ## 为什么恢复暂停的 changefeed 后,changefeed 同步延迟越来越高,数分钟后才恢复正常? 当 changefeed 启动时,为了补齐 changefeed 暂停期间产生的增量数据日志,TiCDC 需要扫描 TiKV 中数据的历史版本,待扫描完毕后,才能够继续推进复制过程,扫描过程可能长达数分钟到数十分钟。 diff --git a/tidb-lightning/tidb-lightning-physical-import-mode.md b/tidb-lightning/tidb-lightning-physical-import-mode.md index d1fcc359f5bc..f925c1dae206 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode.md @@ -92,9 +92,7 @@ backend = "local" - TiDB Lightning 在 v5.4.0 之前不支持导入 `charset=GBK` 的表。 -- TiDB Lightning 与 TiCDC 一起使用时需要注意: - - - TiCDC 无法捕获物理导入模式插入的数据。 +- TiDB Lightning 与 TiCDC 一起使用时的注意事项可以参考[TiDB Lightning 物理导入模式与 TiCDC 的兼容性存在哪些限制](/ticdc/ticdc-faq.md#TiDB Lightning 物理导入模式与 TiCDC 的兼容性存在哪些限制?)。 - TiDB Lightning 与 BR 一起使用时需要注意: From ad05d308cc08b6d1f48edff9af28d8fa116a84a4 Mon Sep 17 00:00:00 2001 From: lidezhu Date: Sat, 9 Aug 2025 19:43:07 +0800 Subject: [PATCH 02/10] small fix --- ticdc/ticdc-faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 4a464ca6b478..1e77248e3d34 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -284,7 +284,7 @@ Open protocol 的输出中 type = 6 即为 null,比如: * 如果只存在 `"d"` 字段则为 `DELETE` 事件 更多信息请参考 [Open protocol Row Changed Event 格式定义](/ticdc/ticdc-open-protocol.md#row-changed-event)。 - + ## TiCDC 占用多少 PD 的存储空间? 在使用 TiCDC 的过程中,你可能会遇到 `etcdserver: mvcc: database space exceeded` 错误,该错误主要与 TiCDC 使用 PD 内部的 etcd 来存储元数据的机制相关。 From 9c5995552b8b32bd31fc8235900b173e62d212e4 Mon Sep 17 00:00:00 2001 From: lidezhu Date: Sat, 9 Aug 2025 19:44:42 +0800 Subject: [PATCH 03/10] small fix --- tidb-lightning/tidb-lightning-physical-import-mode.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-lightning/tidb-lightning-physical-import-mode.md b/tidb-lightning/tidb-lightning-physical-import-mode.md index f925c1dae206..b2d2fd2ff95c 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode.md @@ -92,7 +92,7 @@ backend = "local" - TiDB Lightning 在 v5.4.0 之前不支持导入 `charset=GBK` 的表。 -- TiDB Lightning 与 TiCDC 一起使用时的注意事项可以参考[TiDB Lightning 物理导入模式与 TiCDC 的兼容性存在哪些限制](/ticdc/ticdc-faq.md#TiDB Lightning 物理导入模式与 TiCDC 的兼容性存在哪些限制?)。 +- TiDB Lightning 与 TiCDC 一起使用时的注意事项可以参考[TiDB Lightning 物理导入模式与 TiCDC 的兼容性存在哪些限制](/ticdc/ticdc-faq.md#TiDB-Lightning-物理导入模式与-TiCDC-的兼容性存在哪些限制?)。 - TiDB Lightning 与 BR 一起使用时需要注意: From 41f244dde6eea3b2881a23b09ea79371625185e2 Mon Sep 17 00:00:00 2001 From: lidezhu <47731263+lidezhu@users.noreply.github.com> Date: Thu, 14 Aug 2025 16:53:08 +0800 Subject: [PATCH 04/10] Update ticdc/ticdc-faq.md Co-authored-by: Flowyi --- ticdc/ticdc-faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 1e77248e3d34..7480ba13d6c1 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -362,7 +362,7 @@ TiCDC 需要磁盘是为了缓冲上游写入高峰时下游消费不及时堆 ## TiDB Lightning 物理导入模式与 TiCDC 的兼容性存在哪些限制? -TiDB Lightning [物理导入模式 (Physical Import Mode)](/tidb-lightning/tidb-lightning-physical-import-mode.md) 是直接将数据生成为 SST 文件并导入 TiKV 集群。由于这种导入方式不涉及常规的数据写入流程,因此不会产生 change log 记录。在大多数情况下,changefeed 无法观察到这部分数据的变更。只有在 changefeed 初始化阶段,或者 region 发生变更(如 split/merge/leader 迁移等)触发增量扫描时,才有可能看到这部分数据,因此 changefeed 并不保证能够完整捕获通过 TiDB Lightning 物理导入模式导入的数据。 +TiDB Lightning [物理导入模式 (Physical Import Mode)](/tidb-lightning/tidb-lightning-physical-import-mode.md) 是直接将数据生成为 SST 文件并导入 TiKV 集群。由于这种导入方式不涉及常规的数据写入流程,因此不会产生 change log 记录。在大多数情况下,changefeed 无法观察到这部分数据的变更。只有在 changefeed 初始化阶段,或者 region 发生变更(如 split/merge/leader 迁移等)触发增量扫描时,才有可能看到这部分数据,因此 changefeed 并不能完整捕获通过 TiDB Lightning 物理导入模式导入的数据。 如果 TiDB Lightning 物理导入模式操作的表与 changefeed 监听的表存在重叠,可能由于数据捕获不完整发生各种未知的错误,例如 changefeed 同步卡住,上下游数据不一致等。如需对 TiCDC 同步的表需要使用 TiDB Lightning 物理导入模式,可以按照以下步骤操作 From 1c4792c4606ad5d2ee147ef7ec9994e607a3ba0c Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Fri, 15 Aug 2025 09:16:28 +0800 Subject: [PATCH 05/10] Apply suggestions from code review --- ticdc/ticdc-faq.md | 13 ++++++++----- .../tidb-lightning-physical-import-mode.md | 2 +- 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 7480ba13d6c1..7854da37f5f6 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -362,9 +362,9 @@ TiCDC 需要磁盘是为了缓冲上游写入高峰时下游消费不及时堆 ## TiDB Lightning 物理导入模式与 TiCDC 的兼容性存在哪些限制? -TiDB Lightning [物理导入模式 (Physical Import Mode)](/tidb-lightning/tidb-lightning-physical-import-mode.md) 是直接将数据生成为 SST 文件并导入 TiKV 集群。由于这种导入方式不涉及常规的数据写入流程,因此不会产生 change log 记录。在大多数情况下,changefeed 无法观察到这部分数据的变更。只有在 changefeed 初始化阶段,或者 region 发生变更(如 split/merge/leader 迁移等)触发增量扫描时,才有可能看到这部分数据,因此 changefeed 并不能完整捕获通过 TiDB Lightning 物理导入模式导入的数据。 +TiDB Lightning [物理导入模式 (Physical Import Mode)](/tidb-lightning/tidb-lightning-physical-import-mode.md) 是直接将数据生成为 SST 文件并导入 TiKV 集群。由于这种导入方式不涉及常规的数据写入流程,因此不会产生 change log 记录。在大多数情况下,changefeed 无法观察到这部分数据的变更。只有在 changefeed 初始化阶段,或者 Region 发生变更(如 split/merge/leader 迁移等)触发增量扫描时,才有可能看到这部分数据,因此 changefeed 并不能完整捕获通过 TiDB Lightning 物理导入模式导入的数据。 -如果 TiDB Lightning 物理导入模式操作的表与 changefeed 监听的表存在重叠,可能由于数据捕获不完整发生各种未知的错误,例如 changefeed 同步卡住,上下游数据不一致等。如需对 TiCDC 同步的表需要使用 TiDB Lightning 物理导入模式,可以按照以下步骤操作 +如果 TiDB Lightning 物理导入模式操作的表与 changefeed 监听的表存在重叠,可能由于数据捕获不完整发生各种未知的错误,例如 changefeed 同步卡住,上下游数据不一致等。如需使用 TiDB Lightning 物理导入模式导入 TiCDC 同步的表,可以按照以下步骤操作: 1. 删除涉及这些表的 TiCDC 同步任务。 @@ -376,11 +376,14 @@ TiDB Lightning [物理导入模式 (Physical Import Mode)](/tidb-lightning/tidb- cdc cli changefeed create -c "upstream-to-downstream-some-tables" --start-ts=431434047157698561 --sink-uri="mysql://root@127.0.0.1:4000? time-zone=" ``` -如果可以确认 TiDB Lightning 物理导入模式操作的表与 changefeed 监听的表不存在重叠关系,可以将 [TiDB Lightning 配置文件](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-任务配置) 的 `check-requirements` 设置为 false,强制执行数据导入操作。 +如果可以确认 TiDB Lightning 物理导入模式操作的表与 changefeed 监听的表不存在重叠关系,可以将 [TiDB Lightning 配置文件](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-任务配置) 的 `check-requirements` 设置为 `false`,强制执行数据导入操作。 -## BR(Backup & Restore) 和 TiCDC 的兼容性存在哪些限制? +## BR (Backup & Restore) 和 TiCDC 的兼容性存在哪些限制? -BR(Backup & Restore)工具也是直接将数据生成为 SST 文件并导入 TiKV 集群,如上一节所述,changefeed 并不保证能够完整捕获通过这类方式导入的数据。对于 v8.2.0 之前(不包括 v8.2.0)的版本,如果集群上已存在 changefeed 任务,BR 将拒绝创建恢复任务。对于 v8.2.0 及之后的版本,仅当 BR 恢复数据的 backupTs 小于集群上所有 changefeed 的 checkpointTs 时,才允许创建恢复任务。 +BR (Backup & Restore) 工具也是直接将数据生成为 SST 文件并导入 TiKV 集群,如上一节所述,changefeed 并不保证能够完整捕获通过这类方式导入的数据。不同版本的处理方式不同: + +- 对于 v8.2.0 之前的版本,如果集群上已存在 changefeed 任务,BR 将拒绝创建恢复任务。 +- 从 v8.2.0 开始,仅当 BR 恢复数据的 backupTs 小于集群上所有 changefeed 的 checkpointTs 时,才允许创建恢复任务。 ## 为什么恢复暂停的 changefeed 后,changefeed 同步延迟越来越高,数分钟后才恢复正常? diff --git a/tidb-lightning/tidb-lightning-physical-import-mode.md b/tidb-lightning/tidb-lightning-physical-import-mode.md index b2d2fd2ff95c..768d58724248 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode.md @@ -92,7 +92,7 @@ backend = "local" - TiDB Lightning 在 v5.4.0 之前不支持导入 `charset=GBK` 的表。 -- TiDB Lightning 与 TiCDC 一起使用时的注意事项可以参考[TiDB Lightning 物理导入模式与 TiCDC 的兼容性存在哪些限制](/ticdc/ticdc-faq.md#TiDB-Lightning-物理导入模式与-TiCDC-的兼容性存在哪些限制?)。 +- TiDB Lightning 与 TiCDC 一起使用时的注意事项可以参考 [TiDB Lightning 物理导入模式与 TiCDC 的兼容性存在哪些限制](/ticdc/ticdc-faq.md#tidb-lightning-物理导入模式与-ticdc-的兼容性存在哪些限制)。 - TiDB Lightning 与 BR 一起使用时需要注意: From f92238cb6ef437a44eaf0b7cc7fba9379dfa35fb Mon Sep 17 00:00:00 2001 From: xixirangrang Date: Fri, 15 Aug 2025 09:22:36 +0800 Subject: [PATCH 06/10] Update ticdc/ticdc-faq.md --- ticdc/ticdc-faq.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 7854da37f5f6..674328ac70f5 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -380,7 +380,9 @@ TiDB Lightning [物理导入模式 (Physical Import Mode)](/tidb-lightning/tidb- ## BR (Backup & Restore) 和 TiCDC 的兼容性存在哪些限制? -BR (Backup & Restore) 工具也是直接将数据生成为 SST 文件并导入 TiKV 集群,如上一节所述,changefeed 并不保证能够完整捕获通过这类方式导入的数据。不同版本的处理方式不同: +BR (Backup & Restore) 工具也是直接将数据生成为 SST 文件并导入 TiKV 集群,Changefeed 并不保证能够完整捕获通过这类方式导入的数据。详情参考 [TiDB Lightning 物理导入模式与 TiCDC 的兼容性存在哪些限制](/ticdc/ticdc-faq.md#tidb-lightning-物理导入模式与-ticdc-的兼容性存在哪些限制)。 + +不同版本的 BR 处理方式不同: - 对于 v8.2.0 之前的版本,如果集群上已存在 changefeed 任务,BR 将拒绝创建恢复任务。 - 从 v8.2.0 开始,仅当 BR 恢复数据的 backupTs 小于集群上所有 changefeed 的 checkpointTs 时,才允许创建恢复任务。 From 83aaf6114248157e012d8534545df8e060048d06 Mon Sep 17 00:00:00 2001 From: houfaxin Date: Fri, 15 Aug 2025 09:50:53 +0800 Subject: [PATCH 07/10] fix link --- ticdc/ticdc-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 91c5f87edad7..6257184096f4 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -145,7 +145,7 @@ WHERE `A` = 1 OR `A` = 2; - 暂不支持单独使用 RawKV 的 TiKV 集群。 - 暂不支持在 TiDB 中[创建 SEQUENCE 的 DDL 操作](/sql-statements/sql-statement-create-sequence.md)和 [SEQUENCE 函数](/sql-statements/sql-statement-create-sequence.md#sequence-函数)。在上游 TiDB 使用 SEQUENCE 时,TiCDC 将会忽略掉上游执行的 SEQUENCE DDL 操作/函数,但是使用 SEQUENCE 函数的 DML 操作可以正确地同步。 - 暂不支持对 TiCDC 正在同步的表和库进行 [TiDB Lightning 物理导入](/tidb-lightning/tidb-lightning-physical-import-mode.md)。详情请参考[为什么在上游使用了 TiDB Lightning 和 BR 恢复了数据之后,TiCDC 同步会出现卡顿甚至卡住](/ticdc/ticdc-faq.md#为什么在上游使用了-tidb-lightning-物理导入模式和-br-恢复了数据之后ticdc-同步会出现卡顿甚至卡住)。 -- 在 BR v8.2.0 之前的版本中,当集群存在 TiCDC 同步任务时,BR 不支持进行[数据恢复](/br/backup-and-restore-overview.md)。详情请参考[为什么在上游使用了 TiDB Lightning 和 BR 恢复了数据之后,TiCDC 同步会出现卡顿甚至卡住](/ticdc/ticdc-faq.md#为什么在上游使用了-tidb-lightning-物理导入模式和-br-恢复了数据之后ticdc-同步会出现卡顿甚至卡住)。 +- 在 BR v8.2.0 之前的版本中,当集群存在 TiCDC 同步任务时,BR 不支持进行[数据恢复](/br/backup-and-restore-overview.md)。详情请参考 [BR (Backup & Restore) 和 TiCDC 的兼容性存在哪些限制?](/ticdc/ticdc-faq.md#br-backup--restore-和-ticdc-的兼容性存在哪些限制)。 - 从 BR v8.2.0 起,BR 数据恢复对 TiCDC 的限制被放宽:如果所恢复数据的 BackupTS(即备份时间)早于 Changefeed 的 [CheckpointTS](/ticdc/ticdc-architecture.md#checkpointts)(即记录当前同步进度的时间戳),BR 数据恢复可以正常进行。考虑到 BackupTS 通常较早,此时可以认为绝大部分场景下,当集群存在 TiCDC 同步任务时,BR 都可以进行数据恢复。 对上游存在较大事务的场景提供部分支持,详见 [TiCDC 是否支持同步大事务?有什么风险吗?](/ticdc/ticdc-faq.md#ticdc-支持同步大事务吗有什么风险吗)。 From 1dde274b2904c839bd8394c640a0066bc1acbed7 Mon Sep 17 00:00:00 2001 From: houfaxin Date: Fri, 15 Aug 2025 10:17:31 +0800 Subject: [PATCH 08/10] Update ticdc-overview.md --- ticdc/ticdc-overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 6257184096f4..323f342b2160 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -144,7 +144,7 @@ WHERE `A` = 1 OR `A` = 2; - 暂不支持单独使用 RawKV 的 TiKV 集群。 - 暂不支持在 TiDB 中[创建 SEQUENCE 的 DDL 操作](/sql-statements/sql-statement-create-sequence.md)和 [SEQUENCE 函数](/sql-statements/sql-statement-create-sequence.md#sequence-函数)。在上游 TiDB 使用 SEQUENCE 时,TiCDC 将会忽略掉上游执行的 SEQUENCE DDL 操作/函数,但是使用 SEQUENCE 函数的 DML 操作可以正确地同步。 -- 暂不支持对 TiCDC 正在同步的表和库进行 [TiDB Lightning 物理导入](/tidb-lightning/tidb-lightning-physical-import-mode.md)。详情请参考[为什么在上游使用了 TiDB Lightning 和 BR 恢复了数据之后,TiCDC 同步会出现卡顿甚至卡住](/ticdc/ticdc-faq.md#为什么在上游使用了-tidb-lightning-物理导入模式和-br-恢复了数据之后ticdc-同步会出现卡顿甚至卡住)。 +- 暂不支持对 TiCDC 正在同步的表和库进行 [TiDB Lightning 物理导入](/tidb-lightning/tidb-lightning-physical-import-mode.md)。详情请参考 [TiDB Lightning 物理导入模式与 TiCDC 的兼容性存在哪些限制?](/ticdc/ticdc-faq.md#tidb-lightning-物理导入模式与-ticdc-的兼容性存在哪些限制)。 - 在 BR v8.2.0 之前的版本中,当集群存在 TiCDC 同步任务时,BR 不支持进行[数据恢复](/br/backup-and-restore-overview.md)。详情请参考 [BR (Backup & Restore) 和 TiCDC 的兼容性存在哪些限制?](/ticdc/ticdc-faq.md#br-backup--restore-和-ticdc-的兼容性存在哪些限制)。 - 从 BR v8.2.0 起,BR 数据恢复对 TiCDC 的限制被放宽:如果所恢复数据的 BackupTS(即备份时间)早于 Changefeed 的 [CheckpointTS](/ticdc/ticdc-architecture.md#checkpointts)(即记录当前同步进度的时间戳),BR 数据恢复可以正常进行。考虑到 BackupTS 通常较早,此时可以认为绝大部分场景下,当集群存在 TiCDC 同步任务时,BR 都可以进行数据恢复。 From 0660c203a68aa1efb881cbcba2a11a4fdba39907 Mon Sep 17 00:00:00 2001 From: lidezhu <47731263+lidezhu@users.noreply.github.com> Date: Fri, 15 Aug 2025 12:16:20 +0800 Subject: [PATCH 09/10] Update ticdc/ticdc-faq.md --- ticdc/ticdc-faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 674328ac70f5..b033649ba7d8 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -380,7 +380,7 @@ TiDB Lightning [物理导入模式 (Physical Import Mode)](/tidb-lightning/tidb- ## BR (Backup & Restore) 和 TiCDC 的兼容性存在哪些限制? -BR (Backup & Restore) 工具也是直接将数据生成为 SST 文件并导入 TiKV 集群,Changefeed 并不保证能够完整捕获通过这类方式导入的数据。详情参考 [TiDB Lightning 物理导入模式与 TiCDC 的兼容性存在哪些限制](/ticdc/ticdc-faq.md#tidb-lightning-物理导入模式与-ticdc-的兼容性存在哪些限制)。 +BR (Backup & Restore) 工具也是直接将数据生成为 SST 文件并导入 TiKV 集群,Changefeed 并不能完整捕获通过这类方式导入的数据。详情参考 [TiDB Lightning 物理导入模式与 TiCDC 的兼容性存在哪些限制](/ticdc/ticdc-faq.md#tidb-lightning-物理导入模式与-ticdc-的兼容性存在哪些限制)。 不同版本的 BR 处理方式不同: From d95920d0b9256199b127eccd612a07d4b44d9531 Mon Sep 17 00:00:00 2001 From: lidezhu <47731263+lidezhu@users.noreply.github.com> Date: Fri, 15 Aug 2025 12:18:43 +0800 Subject: [PATCH 10/10] Update ticdc/ticdc-faq.md --- ticdc/ticdc-faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index b033649ba7d8..c6545dc1c566 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -385,7 +385,7 @@ BR (Backup & Restore) 工具也是直接将数据生成为 SST 文件并导入 T 不同版本的 BR 处理方式不同: - 对于 v8.2.0 之前的版本,如果集群上已存在 changefeed 任务,BR 将拒绝创建恢复任务。 -- 从 v8.2.0 开始,仅当 BR 恢复数据的 backupTs 小于集群上所有 changefeed 的 checkpointTs 时,才允许创建恢复任务。 +- 从 v8.2.0 开始,仅当 BR 恢复数据的 `backupTs` 小于集群上所有 changefeed 的 `checkpointTs` 时,才允许创建恢复任务。 ## 为什么恢复暂停的 changefeed 后,changefeed 同步延迟越来越高,数分钟后才恢复正常?