diff --git a/faq/ddl-faq-test03.md b/faq/ddl-faq-test03.md
new file mode 100644
index 000000000000..b24b6edadd84
--- /dev/null
+++ b/faq/ddl-faq-test03.md
@@ -0,0 +1,68 @@
+---
+title: DDL 常见问题
+summary: 介绍 DDL 相关的常见问题。
+---
+
+# DDL 常见问题
+
+本文档介绍 TiDB 中常见的 DDL 问题。
+
+## TiDB DDL 是否支持 DDL 语句间并行?具体的一些运行特征是怎样的?
+
+在 TiDB v6.2 之后,TiDB 提供并发 DDL(concurrent DDL) 执行的能力。 并发 DDL 主要是提供 DDL 语句间的并发执行支持。这里和以前的 DDL 执行将会发生如下变化:
+
+1. 需要判断 DDL 语句间是否有相关性,如果有相关性的 DDL 语句将会按照进入 TiDB 的顺序执行,没有相关性的 DDL 语句可以并发执行。并发判断规则:
+ 1. 相同表上的 DDL 语句之间具有相关性,需要按照进入 TiDB 的顺序执行;
+ 2. 对于 Schema 上的操作,可能会对于 schema 中的表上的 DDL 语句建立相关性,目前 Drop Schema 会对于其包含 Schema 上的 DDL 产生相关性;也需要顺序执行;
+2. 是否所有的 DDL 语句都会并发执行?
+ 当前,答案是否定的,在 TiDB 中 DDL 语句被分为两类,
+ 1. 普通(general)DDL 语句,这类 DDL 语句的执行只需要修改对象的元数据,不需要操作 schema 存储的数据,通常在秒级完成;需要的计算资源相对少;
+ 2. 需要重组(reorg)DDL 语句, 这类 DDL 语句的执行不仅需要修改对象的元数据,也需要对于 schema 存储的数据进行处理,例如:加索引,需要扫描全表数据,来创建索引,需要比较多的计算资源与较长的执行时间;
+ 当前我们仅对于需要重组的 DDL 语句启动了并发执行支持。
+3. 对于启动了并发 DDL 语句支持的 TiDB 集群,DDL 语句间的并发度是如何确定的?
+ 目前因为 DDL 等后台任务的执行可能会占用相当的资源,因此我们采取了一个相对保守的策略来确定 DDL 语句执行的并发度
+ 1. 对于普通 DDL(general DDL) 语句,我们当前语句并发度为 1(后续将会提供并发执行支持);
+ 2. 对于需要重组的 DDL(Reorg DDL)语句,我们的并发度设置规则如下(并发度不允许用户自己设置):
+ TiDB DDL owner 节点容器能够使用的 CPU 资源数量的 1/4 与 1 之间的最大值,例如 8C 规格的 TiDB DDL owner 节点,并发度将会是 2。
+
+## TiDB DDL 的优先级如何定义?
+ 由于 DDL 语句,特别是需要重组的 DDL 语句在执行的过程中可能会占用较多计算或者存储引擎资源,从而导致对于前端用户业务的影响。通过对 DDL 任务设置
+ - [`tidb_ddl_reorg_priority`](/system-variables.md#tidb_ddl_reorg_priority)
+ 对与 DDL 等任务如果用户在业务高峰期间,可以将优先级调低,这样 TiDB 集群会通过优先级降低 DDL 对于集群资源的争抢。
+ - 其他参数的设置可以参考:
+ - [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt)
+ - [`tidb_ddl_reorg_priority`](/system-variables.md#tidb_ddl_reorg_priority)
+ - [`tidb_ddl_error_count_limit`](/system-variables.md#tidb_ddl_error_count_limit)
+ - [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size)
+
+## 快速加索引方式的启动常见问题:
+ 从 TiDB v6.3 开始,我们为 TiDB 用户提供了 快速加索引的模式,可以相对于 v6.1 提升 10倍的速度。我们在 TiDB v6.5 快速加索引模式已经 GA。
+ 这里说明一下从低版本升级上来,的一些检查事项:
+ **TiDB 配置参数**:
+ - [`temp-dir`](/tidb-configuration-file#temp-dir-new-in-v630) 这个参数用来指定快速加索引模式执行本地磁盘路径。
+ - 对于 On Premises 用户, 需要用户提前挂载好 SSD 磁盘,配置好相应路径,然后进行升级操作,重启后检查 TiDB
+ ```sql
+mysql> SHOW CONFIG WHERE type = 'tidb' AND name = 'temp-dir';
++------+---------------------------------------------------------------------------------------------+----------+-----------+
+| Type | Instance | Name | Value |
++------+---------------------------------------------------------------------------------------------+----------+-----------+
+| tidb | tidb-2:4000 | temp-dir | /tmp/tidb |
+| tidb | tidb-1:4000 | temp-dir | /tmp/tidb |
+| tidb | tidb-0:4000 | temp-dir | /tmp/tidb |
++------+---------------------------------------------------------------------------------------------+----------+-----------+
+3 rows in set (0.52 sec)
+```
+ **注意:** 这个是一个配置参数,需要重启 TiDB 节点,上面 `Value` 字段查询出来值应该和用户设置的值应该一致。
+ - 对于 Cloud 用户,我们对于能够使用快速加索引功能的使用有一些限制:
+
+| 描述 | 供应商 | TiDB CPU 规格 | 是否支持快速索引模式 | 备注 |
+|-----------------------|-----|------------------|------------|------|
+| TiDB cloud Dedicated | AWS | 2C vCPU, 4C vCPU | 不支持 | 成本问题 |
+| | | \>= 8C vCPU | 支持 | |
+| | GCP | ALL | 不支持 | |
+
+ TiDB 系统变量设置
+ - [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-从-v630-版本开始引入)
+ 这个系统变量在 TiDB v6.5 默认打开。
+ - [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-从-v630-版本开始引入)
+ 这个系统变量用来控制快速加索引方式本地磁盘能够使用的限额,对于 on Premises 用户来说可以根据实际情况增加这个值。
\ No newline at end of file
diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md
index 0fae68803343..63aa4180f96a 100644
--- a/ticdc/ticdc-faq.md
+++ b/ticdc/ticdc-faq.md
@@ -285,9 +285,26 @@ Open protocol 的输出中 type = 6 即为 null,比如:
更多信息请参考 [Open protocol Row Changed Event 格式定义](/ticdc/ticdc-open-protocol.md#row-changed-event)。
-## TiCDC 占用多少 PD 的存储空间
+## TiCDC 占用多少 PD 的存储空间?
-TiCDC 使用 PD 内部的 etcd 来存储元数据并定期更新。因为 etcd 的多版本并发控制 (MVCC) 以及 PD 默认的 compaction 间隔是 1 小时,TiCDC 占用的 PD 存储空间与 1 小时内元数据的版本数量成正比。在 v4.0.5、v4.0.6、v4.0.7 三个版本中 TiCDC 存在元数据写入频繁的问题,如果 1 小时内有 1000 张表创建或调度,就会用尽 etcd 的存储空间,出现 `etcdserver: mvcc: database space exceeded` 错误。出现这种错误后需要清理 etcd 存储空间,参考 [etcd maintenance space-quota](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota)。如果你的 TiCDC 版本为 v4.0.5、v4.0.6 或 v4.0.7,建议升级到 v4.0.9 及以后版本。
+在使用 TiCDC 的过程中,可能会遇到 `etcdserver: mvcc: database space exceeded` 错误,这主要与 TiCDC 使用 PD 内部的 etcd 来存储元数据的机制相关。
+
+etcd 采用多版本并发控制(MVCC)机制存储数据,且 PD 默认的 compaction 间隔为 1 小时。这意味着在 1 小时内,etcd 会保留所有数据的多个版本,直至进行压缩操作。
+
+**v6.0.0 之前版本的问题**
+
+在 v6.0.0 之前,TiCDC 会使用 PD 内部的 etcd 来存储和更新 changefeed 内部所有表的元数据。因此,TiCDC 占用的 PD 存储空间与 changefeed 所同步的表的数量成正比。当同步表数量较多时,etcd 的存储空间会被更快耗尽,更易出现 `etcdserver: mvcc: database space exceeded` 错误。
+
+**TiCDC 在特定版本的问题**
+
+在 v4.0.5、v4.0.6、v4.0.7 这三个版本中,TiCDC 存在元数据写入频繁的问题。若 1 小时内有 1000 张表创建或调度,产生的大量元数据版本会快速占用 etcd 的存储空间,从而引发上述错误。
+
+**解决方法**
+
+出现这种错误后需要清理 etcd 存储空间,参考 [etcd maintenance space-quota](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota)。
+
+**v6.0.0 及以后版本的优化**
+如果您的 TiCDC 版本小于 v6.0.0,建议升级到 v6.0.0 及以后版本。新版本对元数据存储机制进行了优化,可有效避免因上述原因导致的 etcd 存储空间问题。
## TiCDC 支持同步大事务吗?有什么风险吗?
@@ -438,3 +455,49 @@ TiDB 有事务超时的机制,当事务运行超过 [`max-txn-ttl`](/tidb-conf
> **注意:**
>
> 当同步存储生成列到 Kafka 或存储服务后,再将其写回 MySQL 时,可能会遇到 `Error 3105 (HY000): The value specified for generated column 'xx' in table 'xxx' is not allowed` 错误。为避免该错误,你可以使用 [Open Protocol](/ticdc/ticdc-open-protocol.md) 进行同步。该协议的输出包含[列的 flag 值](/ticdc/ticdc-open-protocol.md#列标志位),可以区分是否为生成列。
+
+## 当频繁出现 `ErrMySQLDuplicateEntry` 错误时,如何解决?
+
+使用 TiCDC 将数据同步到 TiDB 或 MySQL 时,如果上游以特定模式执行 SQL ,可能会遇到如下错误:
+
+`CDC:ErrMySQLDuplicateEntryCDC`
+
+具体来说,TiDB 会将同一事务内对同一行的 `DELETE + INSERT` 操作提交为一个 `UPDATE` 行变更。当 TiCDC 向下游以 UPDATE 的形式进行同步时,尝试交换唯一键值的 UPDATE 操作会出现冲突。
+
+考虑以下表:
+
+```sql
+CREATE TABLE data_table (
+ id BIGINT(20) NOT NULL PRIMARY KEY,
+ value BINARY(16) NOT NULL,
+ UNIQUE KEY value_index (value)
+) CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
+```
+
+如果上游事务尝试交换两行的 `value` 字段:
+
+```sql
+DELETE FROM data_table WHERE id = 1;
+DELETE FROM data_table WHERE id = 2;
+INSERT INTO data_table (id, value) VALUES (1, 'v3');
+INSERT INTO data_table (id, value) VALUES (2, 'v1');
+```
+
+TiDB 内部实际上会产生两条 UPDATE 行变更,这些行变更被 TiCDC 捕捉到之后,会被翻译成两条 UPDATE 语句向下游同步:
+
+```sql
+UPDATE data_table SET value = 'v3' WHERE id = 1;
+UPDATE data_table SET value = 'v1' WHERE id = 2;
+```
+
+如果在执行第二个更新时,表中仍然存在`v1`,会破坏唯一键约束,从而导致 `ErrMySQLDuplicateEntry` 错误。
+
+为防止此问题,可以通过在 `sink-uri` 配置中设置 `safe-mode=true` 参数,在TiCDC中启用安全模式。这样,TiCDC 就会把 UPDATE 操作拆分为 `DELETE + INSERT` 进行执行,这样就能避免错误。
+
+按如下方式修改TiCDC的 sink URI:
+
+```
+mysql://user:password@host:port/?safe-mode=true
+```
+
+如果你频繁遇到上述错误,那么可以考虑启用 safe-mode 以解决问题。
\ No newline at end of file
diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md
index fc69a7d23c4c..eb90d7bd368b 100644
--- a/tikv-configuration-file.md
+++ b/tikv-configuration-file.md
@@ -219,6 +219,11 @@ TiKV 配置文件比命令行参数支持更多的选项。你可以在 [etc/con
+ 默认值:60s
+ 最小值:1s
+### end-point-memory-quota 从 v8.2.0 版本开始引入
+
+* TiKV Coproccessor 请求可以使用的内存上限,超过该值后后续的 Coprocessor 请求将被拒绝并报错(server is busy)。
+* 默认值:系统总内存大小的 45%(如果超过 500MB,则默认值为 500MB)。
+
### `snap-io-max-bytes-per-sec`
+ 处理 snapshot 时最大允许使用的磁盘带宽。
@@ -503,6 +508,11 @@ TiKV 配置文件比命令行参数支持更多的选项。你可以在 [etc/con
> - 由于 API V1 和 API V2 底层存储格式不同,因此**仅当** TiKV 中只有 TiDB 数据时,可以平滑启用或关闭 API V2。其他情况下,需要新建集群,并使用 [TiKV Backup & Restore](https://tikv.org/docs/latest/concepts/explore-tikv-features/backup-restore-cn/) 工具进行数据迁移。
> - 启用 API V2 后,**不能**将 TiKV 集群回退到 v6.1.0 之前的版本,否则可能导致数据损坏。
+## txn-status-cache-capacity 从 v7.6.0 版本开始引入
+
++ 设置 TiKV 内的事务状态 cache 的容量。不建议用户随意修改。
++ 默认值:5120000
+
## storage.block-cache
RocksDB 多个 CF 之间共享 block cache 的配置选项。
@@ -1049,6 +1059,41 @@ raftstore 相关的配置项。
+ 控制 TiKV 执行周期性全量数据整理时的 CPU 使用率阈值。
+ 默认值:`0.1`,表示全量数据整理进程的最大 CPU 使用率为 10%。
+### follower-read-max-log-gap 从 v7.4.0 版本开始引入
+
++ follower 处理读请求时允许的最大日志落后数目,超出则拒绝读请求。
++ 默认值:100
+
+### inspect-cpu-util-thd 从 v7.6.0 版本开始引入
+
++ TiKV 进行慢节点检测时判定节点 CPU 是否处于繁忙状态的阈值。范围 [0%, 100%]。
++ 默认值:40%
+
+### inspect-kvdb-interval 从 v8.1.2 版本开始引入
+
++ TiKV 进行慢节点检测时检查 KV 盘的间隔和超时时间。如果 KVDB 和 RaftDB 使用相同的挂载路径,该值将被覆盖为 0(不检测)。
++ 默认值:2s
+
+### min-pending-apply-region-count 从 v8.0.0 版本开始引入
+
++ TiKV 启动服务时,处于忙于应用 Raft 日志状态的 Region 的最大个数。只有当忙于应用 Raft 日志的 Region 数量低于该值时,Raftstore 才能接受 leader 迁移,以减少滚动重启期间的可用性下降。
++ 默认值:10
+
+### request-voter-replicated-index-interval 从 v6.6.0 版本开始引入
+
++ 控制 Witness 节点定期从投票节点获取已复制的 Raft 日志位置的时间间隔。
++ 默认值:5分钟
+
+### slow-trend-unsensitive-cause 从 v6.6.0 版本开始引入
+
++ TiKV 采用 SlowTrend 检测算法时,延时检测的敏感性。值越高表示敏感度越低。
++ 默认值:10
+
+### slow-trend-unsensitive-result 从 v6.6.0 版本开始引入
+
++ TiKV 采用 SlowStrend 检测算法时,QPS 侧检测的敏感性。值越高表示敏感度越低。
++ 默认值:0.5
+
## coprocessor
Coprocessor 相关的配置项。
@@ -1349,6 +1394,11 @@ RocksDB 相关的配置项。
+ `true`:在 MANIFEST 文件中记录 WAL 文件的信息,并在启动时验证 WAL 文件的完整性。
+ `false`:不在 MANIFEST 文件中记录 WAL 文件的信息,而且不在启动时验证 WAL 文件的完整性。
+### enable-multi-batch-write 从 v6.2.0 版本开始引入
+
++ 开启 RocksDB 写入优化,将 WriteBatch 中的内容并发写入到 memtable 中,缩短写入耗时。
++ 默认值:无,但在默认情况下会自动开启,除非手动设置成 false 或者开启 `rocksdb.enable-pipelined-write` 或 `rocksdb.enable-unordered-write`。
+
## rocksdb.titan
Titan 相关的配置项。
@@ -1380,7 +1430,7 @@ Titan 相关的配置项。
+ 默认值:4
+ 最小值:1
-## rocksdb.defaultcf | rocksdb.writecf | rocksdb.lockcf
+## rocksdb.defaultcf | rocksdb.writecf | rocksdb.lockcf | rocksdb.raftcf
rocksdb defaultcf、rocksdb writecf 和 rocksdb lockcf 相关的配置项。
@@ -1646,6 +1696,11 @@ rocksdb defaultcf、rocksdb writecf 和 rocksdb lockcf 相关的配置项。
+ 默认值:无,表示默认不触发此 compaction。
+ 单位:s(second)|h(hour)|d(day)
+### `max-compactions` 从 v6.6.0 版本开始引入
+
++ 最大 compaction 任务并发数。0 表示不限制。
++ 默认值:0
+
## rocksdb.defaultcf.titan
> **注意:**
@@ -2028,6 +2083,12 @@ Raft Engine 相关的配置项。
+ 控制 Raft Engine 是否自动生成空的日志文件用于日志回收。该配置项启用时,Raft Engine 将在初始化时自动填充一批空日志文件用于日志回收,保证日志回收在初始化后立即生效。
+ 默认值:`false`
+### `compression-level` 从 v7.4.0 版本开始引入
+
++ 设置 raft-engine 在写 raft log 文件时所采用的 lz4 压缩算法的压缩效率,范围 [1, 16],越低压缩速率越高,但压缩率越低。
+
++ 默认值:1
+
## security
安全相关配置项。
@@ -2517,6 +2578,8 @@ TiKV MVCC 内存引擎 (In-Memory Engine) 在 TiKV 存储层相关的配置项
+ 是否开启内存引擎以加速多版本查询。关于内存引擎的详细信息,参见 [TiKV MVCC 内存引擎](/tikv-in-memory-engine.md)。
+ 默认值:false(即关闭内存引擎)
++ 建议 TiKV 节点至少配置 8 GiB 内存,推荐配置 32 GiB 或更多内存以获得更佳性能。
++ 如果 TiKV 可用内存过低,即使将该配置项设置为 `true`,内存引擎也不会被启用。此时,你可以在 TiKV 的日志文件中查找与 `"in-memory engine is disabled because"` 相关的日志信息,以判断为何内存引擎未能启用。
### `capacity` 从 v8.5.0 版本开始引入