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 (*号) 不会被同步，并且导致后续数据同步失败。
+> - 之前不存在有效索引，创建第一个**有效索引**的 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 在两个 TiDB 集群间同步数据时，如果上下游的延迟超过 100 ms：
-    - 对于 v6.5.2 之前的版本，推荐将 TiCDC 部署在下游 TiDB 集群所在的区域 (IDC, region)
-    - 经过优化后，对于 v6.5.2 及之后的版本，推荐将 TiCDC 部署在上游集群所在的区域 (IDC, region)。
-- TiCDC 同步的表需要至少存在一个**有效索引**的表，**有效索引**的定义如下：
+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 同步的表需要至少存在一个[**有效索引**](#有效索引)的表。
 - 在使用 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-支持同步大事务吗有什么风险吗)。