From dfcfe160b4d97759ae91102c6cb2ae4c473de254 Mon Sep 17 00:00:00 2001 From: Ti Chi Robot Date: Thu, 31 Oct 2024 11:40:51 +0800 Subject: [PATCH] cdc: remove mention about force-replicate (#19249) (#19265) --- ticdc/ticdc-overview.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 0723d2d098c3a..d349a6b08ed9a 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -82,10 +82,6 @@ As shown in the preceding architecture diagram, TiCDC supports replicating data - To ensure eventual consistency when using TiCDC for disaster recovery, you need to configure [redo log](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios) and ensure that the storage system where the redo log is written can be read normally when a disaster occurs in the upstream. -> **Note:** -> -> Since v4.0.8, TiCDC supports replicating tables **without a valid index** by modifying the task configuration. However, this compromises the guarantee of data consistency to some extent. For more details, see [Replicate tables without a valid index](/ticdc/ticdc-manage-changefeed.md#replicate-tables-without-a-valid-index). - ## Implementation of processing data changes This section mainly describes how TiCDC processes data changes generated by upstream DML operations.