From 878c2fe8698ca605cbd335470ede761ece04bed0 Mon Sep 17 00:00:00 2001 From: Aolin Date: Tue, 28 Nov 2023 14:28:16 +0800 Subject: [PATCH 1/2] This is an automated cherry-pick of #15494 Signed-off-by: ti-chi-bot --- ticdc/ticdc-overview.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 05d9f854426c3..4d18045112300 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -80,8 +80,12 @@ As shown in the architecture diagram, TiCDC supports replicating data to TiDB, M - A primary key (`PRIMARY KEY`) is a valid index. - A unique index (`UNIQUE INDEX`) is valid if every column of the index is explicitly defined as non-nullable (`NOT NULL`) and the index does not have a virtual generated column (`VIRTUAL GENERATED COLUMNS`). +<<<<<<< HEAD - To use TiCDC in disaster recovery scenarios, you need to configure [redo log](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios). - When you replicate a wide table with a large single row (greater than 1K), it is recommended to configure the [`per-table-memory-quota`](/ticdc/ticdc-server-config.md) so that `per-table-memory-quota` = `ticdcTotalMemory`/(`tableCount` * 2). `ticdcTotalMemory` is the memory of a TiCDC node, and `tableCount` is the number of target tables that a TiCDC node replicates. +======= +- 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. +>>>>>>> 321c01325b (ticdc: update best practices (#15494)) ## Unsupported scenarios From ef8e6aade2d4415ceb8692530f10d5e1aba731b9 Mon Sep 17 00:00:00 2001 From: Aolin Date: Tue, 28 Nov 2023 14:49:44 +0800 Subject: [PATCH 2/2] resolve conflicts --- ticdc/ticdc-overview.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 4d18045112300..d49e7172c7d92 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -80,12 +80,8 @@ As shown in the architecture diagram, TiCDC supports replicating data to TiDB, M - A primary key (`PRIMARY KEY`) is a valid index. - A unique index (`UNIQUE INDEX`) is valid if every column of the index is explicitly defined as non-nullable (`NOT NULL`) and the index does not have a virtual generated column (`VIRTUAL GENERATED COLUMNS`). -<<<<<<< HEAD -- To use TiCDC in disaster recovery scenarios, you need to configure [redo log](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios). -- When you replicate a wide table with a large single row (greater than 1K), it is recommended to configure the [`per-table-memory-quota`](/ticdc/ticdc-server-config.md) so that `per-table-memory-quota` = `ticdcTotalMemory`/(`tableCount` * 2). `ticdcTotalMemory` is the memory of a TiCDC node, and `tableCount` is the number of target tables that a TiCDC node replicates. -======= - 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. ->>>>>>> 321c01325b (ticdc: update best practices (#15494)) +- When you replicate a wide table with a large single row (greater than 1K), it is recommended to configure the [`per-table-memory-quota`](/ticdc/ticdc-server-config.md) so that `per-table-memory-quota` = `ticdcTotalMemory`/(`tableCount` * 2). `ticdcTotalMemory` is the memory of a TiCDC node, and `tableCount` is the number of target tables that a TiCDC node replicates. ## Unsupported scenarios