ticdc: update doc about ddl white list

ticdc/ticdc-changefeed-config.md

@@ -45,6 +45,10 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl
 # 该配置会同时影响 filter 和 sink 相关配置。自 v6.5.6、v7.1.3 和 v7.5.0 起，默认值由 true 改为 false
 case-sensitive = false
 
+# 指定是否强制同步不存在有效索引的表，默认值为 false
+# 详情请参考：https://docs.pingcap.com/zh/tidb/stable/ticdc-manage-changefeed#同步没有有效索引的表
+force-replicate=false
+
 # 是否开启 Syncpoint 功能，从 v6.3.0 开始支持，该功能默认关闭。
 # 从 v6.4.0 开始，使用 Syncpoint 功能需要同步任务拥有下游集群的 SYSTEM_VARIABLES_ADMIN 或者 SUPER 权限。
 # 注意：该参数只有当下游为 TiDB 时，才会生效。

ticdc/ticdc-ddl.md

@@ -11,38 +11,49 @@ summary: 了解 TiCDC 支持同步的 DDL 和一些特殊情况
 
 目前 TiCDC 在同步 DDL 时使用白名单策略，只有在白名单中的 DDL 操作才会被同步到下游系统，不在白名单中的 DDL 操作将不会被 TiCDC 同步。
 
-以下为 TiCDC 支持同步的 DDL 的列表。
-
-- create database
-- drop database
-- create table 
-- drop table 
-- add column 
-- drop column
-- create index / add index 
-- drop index 
-- truncate table 
-- modify column 
-- rename table 
-- alter column default value
-- alter table comment 
-- rename index 
-- add partition
-- drop partition 
-- truncate partition 
-- create view 
-- drop view 
-- alter table character set 
-- alter database character set
-- recover table 
-- add primary key 
-- drop primary key 
-- rebase auto id
-- alter table index visibility 
-- exchange partition 
-- reorganize partition 
-- alter table ttl 
-- alter table remove ttl
+以下为 TiCDC 支持同步的 DDL 的列表。这些 DDL 会根据是否具有[有效索引](/ticdc/ticdc-overview.md#有效索引)以及是否设置 force-replicate = true 会有不同的行为。下表中出现的缩写字母含义如下：
+
+- Y：在该条件下可以同步到下游。
+- N：在该条件下不会同步到下游。
+
+| DDL| 存在有效索引 | 没有有效索引 | force-replicate = true |
+|---|:---:|:---:| :---: |
+| create database | Y | Y | Y | 
+| drop database | Y | Y | Y |
+| alter database character set | Y | Y | Y |
+| create index / add index | Y | Y* | Y | 
+| drop index | Y* | N | Y |
+| add primary key | Y | Y* | Y |
+| drop primary key | Y* | N | Y |
+| create table  | Y | N | Y |
+| drop table  | Y | N | Y |
+| add column  | Y | N | Y |
+| drop column | Y | N | Y |
+| truncate table  | Y | N | Y |
+| modify column  | Y | N | Y |
+| rename table  | Y | N | Y |
+| alter column default value | Y | N | Y |
+| alter table comment  | Y | N | Y |
+| rename index  | Y | N | Y |
+| add partition | Y | N | Y |
+| drop partition | Y | N | Y |
+| truncate partition | Y | N | Y |
+| create view | Y | N | Y |
+| drop view | Y | N | Y |
+| alter table character set | Y | N | Y |
+| recover table | Y | N | Y |
+| rebase auto id | Y | N | Y |
+| alter table index visibility | Y | N | Y |
+| exchange partition | Y | N | Y |
+| reorganize partition | Y | N | Y |
+| alter table ttl | Y | N | Y |
+| alter table remove ttl | Y | N | Y |
+
+> **注意**
+>
+> - 删除最后一个**有效索引**的 DDL (*号) 不会被同步，并且导致后续数据同步失败。
+> - 当上游表不存在有效索引，且不开启 `force-replicate=true`时，该表不会被同步，但是之后在该表上创建**有效索引**的 DDL (*号) 会被同步，并且下游表和上游表结构可能产生不一致从而导致后续数据同步失败。
+> - 当 changefeed 的配置文件设置 `force-replicate=true` 时，同步任务会尝试强制[同步没有有效索引的表](/ticdc/ticdc-manage-changefeed.md#同步没有有效索引的表)。
 
 ## DDL 同步注意事项
 

ticdc/ticdc-overview.md

@@ -66,16 +66,23 @@ TiCDC 作为 TiDB 的增量数据同步工具，通过 PD 内部的 etcd 实现
 
 另外，从上面的架构图中也可以看到，目前 TiCDC 支持将数据同步到 TiDB、MySQL 数据库、Kafka 以及存储服务等。
 
+## 有效索引
+
+TiCDC一般情况下只会同步存在有效索引的表，有效索引的定义如下：
+
+- 主键 (`PRIMARY KEY`) 为有效索引。
+- 唯一索引 (`UNIQUE INDEX`) 中每一列在表结构中明确定义非空 (`NOT NULL`) 且不存在虚拟生成列 (`VIRTUAL GENERATED COLUMNS`)。
+
+> **注意：**
+>
+> 在设置 force-replicate=true 后，TiCDC会强制[同步没有有效索引的表](/ticdc/ticdc-manage-changefeed.md#同步没有有效索引的表)。
+
 ## 最佳实践
 
 - 使用 TiCDC 在两个 TiDB 集群间同步数据时，如果上下游的延迟超过 100 ms：
     - 对于 v6.5.2 之前的版本，推荐将 TiCDC 部署在下游 TiDB 集群所在的区域 (IDC, region)
     - 经过优化后，对于 v6.5.2 及之后的版本，推荐将 TiCDC 部署在上游集群所在的区域 (IDC, region)。
-- TiCDC 同步的表需要至少存在一个**有效索引**的表，**有效索引**的定义如下：
-
-    - 主键 (`PRIMARY KEY`) 为有效索引。
-    - 唯一索引 (`UNIQUE INDEX`) 中每一列在表结构中明确定义非空 (`NOT NULL`) 且不存在虚拟生成列 (`VIRTUAL GENERATED COLUMNS`)。
-
+- TiCDC 同步的表需要至少存在一个[**有效索引**](#有效索引)的表。
 - 在使用 TiCDC 实现容灾的场景下，为实现最终一致性，需要配置 [redo log](/ticdc/ticdc-sink-to-mysql.md#灾难场景的最终一致性复制) 并确保 redo log 写入的存储系统在上游发生灾难时可以正常读取。
 
 ## TiCDC 处理数据变更的实现原理
@@ -141,4 +148,4 @@ WHERE `A` = 1 OR `A` = 2;
 - 在 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 起，BR 数据恢复对 TiCDC 的限制被放宽：如果所恢复数据的 BackupTS（即备份时间）早于 Changefeed 的 [CheckpointTS](/ticdc/ticdc-architecture.md#checkpointts)（即记录当前同步进度的时间戳），BR 数据恢复可以正常进行。考虑到 BackupTS 通常较早，此时可以认为绝大部分场景下，当集群存在 TiCDC 同步任务时，BR 都可以进行数据恢复。
 
-对上游存在较大事务的场景提供部分支持，详见 [TiCDC 是否支持同步大事务？有什么风险吗？](/ticdc/ticdc-faq.md#ticdc-支持同步大事务吗有什么风险吗)。
+对上游存在较大事务的场景提供部分支持，详见 [TiCDC 是否支持同步大事务？有什么风险吗？](/ticdc/ticdc-faq.md#ticdc-支持同步大事务吗有什么风险吗)。