ticdc: improve description about ticdc compatibility with lightning & BR

ticdc/ticdc-faq.md

@@ -369,22 +369,34 @@ In v6.1.3 and later versions, the default value of `safe-mode` changes to `false
 
 When upstream write traffic is at peak hours, the downstream may fail to consume all data in a timely manner, resulting in data pile-up. TiCDC uses disks to process the data that is piled up. TiCDC needs to write data to disks during normal operation. However, this is not usually the bottleneck for replication throughput and replication latency, given that writing to disks only results in latency within a hundred milliseconds. TiCDC also uses memory to accelerate reading data from disks to improve replication performance.
 
-## Why does replication using TiCDC stall or even stop after data restore using TiDB Lightning physical import mode and BR from upstream?
+## What are the compatibility limitations between TiDB Lightning Physical Import Mode and TiCDC?
 
-Currently, TiCDC is not yet fully compatible with [TiDB Lightning physical import mode](/tidb-lightning/tidb-lightning-physical-import-mode.md) and BR. Therefore, avoid using TiDB Lightning physical import mode and BR on tables that are replicated by TiCDC. Otherwise, unknown errors might occur, such as TiCDC replication getting stuck, a significant spike in replication latency, or data loss.
+TiDB Lightning [Physical Import Mode](/tidb-lightning/tidb-lightning-physical-import-mode.md) directly generates SST files and imports them into the TiKV cluster. Since this import method does not involve the regular data writing process, it does not generate change log records. In most cases, a changefeed cannot observe this kind of data change. Only during the initialization phase of the changefeed or when Region changes (such as split/merge/leader transfer) trigger incremental scans might this kind of data change be observed. Therefore, a changefeed cannot fully capture data imported via TiDB Lightning Physical Import Mode.
 
-If you need to use TiDB Lightning physical import mode or BR to restore data for some tables replicated by TiCDC, take these steps:
+If the tables operated by TiDB Lightning Physical Import Mode overlap with the tables monitored by the changefeed, various unknown errors may occur due to incomplete data capture, such as a changefeed stalling or data inconsistency between upstream and downstream. If you need to use TiDB Lightning Physical Import Mode to import tables replicated by TiCDC, follow these steps:
 
 1. Remove the TiCDC replication task related to these tables.
 
-2. Use TiDB Lightning physical import mode or BR to restore data separately in the upstream and downstream clusters of TiCDC.
+2. Use TiDB Lightning physical import mode to restore data separately in the upstream and downstream clusters of TiCDC.
 
-3. After the restoration is complete and data consistency between the upstream and downstream clusters is verified, create a new TiCDC replication task for incremental replication, with the timestamp (TSO) from the upstream backup as the `start-ts` for the task. For example, assuming the snapshot timestamp of the BR backup in the upstream cluster is `431434047157698561`, you can create a new TiCDC replication task using the following command:
+3. After the restoration is complete and the data consistency of the corresponding tables in the upstream and downstream clusters has been verified, use the timestamp (TSO) after the completion of TiDB Lightning Physical Import Mode as the start-ts of the TiCDC replication task to create a new TiCDC replication task for incremental replication.
 
     ```shell
     cdc cli changefeed create -c "upstream-to-downstream-some-tables" --start-ts=431434047157698561 --sink-uri="mysql://[email protected]:4000? time-zone="
     ```
 
+If you can confirm that the tables operated by TiDB Lightning Physical Import Mode do not overlap with the tables monitored by the changefeed, you can set the `check-requirements` in the TiDB Lightning configuration file to `false` to forcibly execute the data import operation.
+
+## What are the compatibility limitations between BR (Backup & Restore) and TiCDC?
+
+BR (Backup & Restore) also directly generates SST files and imports them into the TiKV cluster. Changefeeds do not guarantee the ability to fully capture data imported in this manner. For details, refer to [What are the compatibility limitations between TiDB Lightning Physical Import Mode and TiCDC?](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-tidb-lightning-physical-import-mode-and-ticdc).
+
+Different versions of BR handle this differently:
+
+- For versions before v8.2.0, if a changefeed task already exists on the cluster, BR will refuse to create a restore task.
+
+- Starting from v8.2.0, a restore task is only allowed to be created if the backupTs of the data restored by BR is earlier than the checkpointTs of all changefeeds on the cluster.
+
 ## After a changefeed resumes from pause, its replication latency gets higher and higher and returns to normal only after a few minutes. Why?
 
 When a changefeed is resumed, TiCDC needs to scan the historical versions of data in TiKV to catch up with the incremental data logs generated during the pause. The replication process proceeds only after the scan is completed. The scan process might take several to tens of minutes.

ticdc/ticdc-overview.md

@@ -156,8 +156,8 @@ Currently, the following scenarios are not supported:
 
 - A TiKV cluster that uses RawKV alone.
 - The [`CREATE SEQUENCE` DDL operation](/sql-statements/sql-statement-create-sequence.md) and the [`SEQUENCE` function](/sql-statements/sql-statement-create-sequence.md#sequence-function) in TiDB. When the upstream TiDB uses `SEQUENCE`, TiCDC ignores `SEQUENCE` DDL operations/functions performed upstream. However, DML operations using `SEQUENCE` functions can be correctly replicated.
-- Currently, performing [TiDB Lightning physical import](/tidb-lightning/tidb-lightning-physical-import-mode.md) on tables and databases that are being replicated by TiCDC is not supported. For more information, see [Why does replication using TiCDC stall or even stop after data restore using TiDB Lightning and BR from upstream](/ticdc/ticdc-faq.md#why-does-replication-using-ticdc-stall-or-even-stop-after-data-restore-using-tidb-lightning-physical-import-mode-and-br-from-upstream).
-- Before v8.2.0, BR does not support [restoring data](/br/backup-and-restore-overview.md) for a cluster with TiCDC replication tasks. For more information, see [Why does replication using TiCDC stall or even stop after data restore using TiDB Lightning and BR from upstream](/ticdc/ticdc-faq.md#why-does-replication-using-ticdc-stall-or-even-stop-after-data-restore-using-tidb-lightning-physical-import-mode-and-br-from-upstream).
+- Currently, performing [TiDB Lightning physical import](/tidb-lightning/tidb-lightning-physical-import-mode.md) on tables and databases that are being replicated by TiCDC is not supported. For more information, see [What are the compatibility limitations between TiDB Lightning Physical Import Mode and TiCDC?](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-tidb-lightning-physical-import-mode-and-ticdc).
+- Before v8.2.0, BR does not support [restoring data](/br/backup-and-restore-overview.md) for a cluster with TiCDC replication tasks. For more information, see [What are the compatibility limitations between BR (Backup & Restore) and TiCDC?](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-br-backup--restore-and-ticdc).
 - Starting from v8.2.0, BR relaxes the restrictions on data restoration for TiCDC: if the `BackupTS` (the backup time) of the data to be restored is earlier than the changefeed [`CheckpointTS`](/ticdc/ticdc-architecture.md#checkpointts) (the timestamp that indicates the current replication progress), BR can proceed with the data restoration normally. Considering that the `BackupTS` is usually much earlier, it can be assumed that in most scenarios, BR supports restoring data for a cluster with TiCDC replication tasks.
 
 TiCDC only partially supports scenarios involving large transactions in the upstream. For details, refer to the [TiCDC FAQ](/ticdc/ticdc-faq.md#does-ticdc-support-replicating-large-transactions-is-there-any-risk), where you can find details on whether TiCDC supports replicating large transactions and any associated risks.

tidb-lightning/tidb-lightning-physical-import-mode.md

@@ -89,9 +89,7 @@ It is recommended that you allocate CPU more than 32 cores and memory greater th
 
     - TiDB Lightning earlier than v5.4.0 cannot import tables of `charset=GBK`.
 
-- When you use TiDB Lightning with TiCDC, note the following:
-
-    - TiCDC cannot capture the data inserted in the physical import mode.
+- For considerations when using TiDB Lightning together with TiCDC, please refer to [What are the compatibility limitations between TiDB Lightning Physical Import Mode and TiCDC?](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-tidb-lightning-physical-import-mode-and-ticdc).
 
 - When you use TiDB Lightning with BR, note the following: