pingcap · 3AceShowHand · Aug 22, 2022 · Aug 23, 2022 · Aug 24, 2022 · Sep 13, 2022
diff --git a/ticdc/deploy-ticdc.md b/ticdc/deploy-ticdc.md
@@ -1,11 +1,14 @@
 ---
-title: TiCDC 安装部署
-summary: 了解 TiCDC 软硬件环境要求以及如何安装部署 TiCDC。
+title: TiCDC 集群部署运维
+summary: 了解 TiCDC 软硬件环境要求以及如何部署运维 TiCDC。
 ---
 
-# TiCDC 安装部署
+# TiCDC 集群部署
 
-本文档介绍 TiCDC 集群的软硬件环境要求，以及如何安装部署 TiCDC 集群。你可以选择随新集群一起部署 TiCDC，也可以对原有 TiDB 集群新增 TiCDC 组件。通常推荐使用 TiUP 完成部署，如有特殊情况也可以用 binary 部署。
+本文档主要包括如下内容：
+
+* 介绍 TiCDC 集群的软硬件环境要求。
+* 使用 TiUP 部署运维 TiCDC 集群。
 
 ## 软件和硬件环境推荐配置
 
@@ -22,19 +25,25 @@ summary: 了解 TiCDC 软硬件环境要求以及如何安装部署 TiCDC。
 
 更多信息参见 [TiDB 软件和硬件环境建议配置](/hardware-and-software-requirements.md)。
 
-## 使用 TiUP 部署包含 TiCDC 组件的全新 TiDB 集群
+## 使用 TiUP 部署 TiCDC
+
+TiCDC 支持基于 Kubernetes 环境部署，详情参考 [在 Kubernetes 上部署 TiCDC](https://docs.pingcap.com/zh/tidb-in-kubernetes/dev/deploy-ticdc)。
+
+TiUP 是 TiDB 集群在 On-Premises 环境的部署工具，支持对 TiCDC 集群执行升级、扩容、缩容、参数配置修改等操作。本文档主要介绍如何使用 TiUP 部署运维 TiCDC 集群，如有特殊情况也可以用 binary 部署。用户可以选择在部署新的 TiDB 集群时一起部署 TiCDC，也可以对原有 TiDB 集群新增 TiCDC 组件。
+
+### 部署全新含有 TiCDC 组件的 TiDB 集群
 
 在使用 TiUP 部署全新 TiDB 集群时，支持同时部署 TiCDC 组件。只需在 TiUP 启动 TiDB 集群时的配置文件中加入 `TiCDC` 部分即可，详细操作参考[编辑初始化配置文件](/production-deployment-using-tiup.md#第-3-步初始化集群拓扑文件)，具体可配置字段参考[通过 TiUP 配置 `cdc_servers`](/tiup/tiup-cluster-topology-reference.md#cdc_servers)。
 
-## 使用 TiUP 在原有 TiDB 集群上新增 TiCDC 组件
+### 在现有 TiDB 集群新增 TiCDC 组件
 
-目前也支持在原有 TiDB 集群上使用 TiUP 新增 TiCDC 组件，操作步骤如下：
+使用 TiUP，在现有 TiDB 集群中新增 TiCDC 组件，操作步骤如下：
 
 1. 首先确认当前 TiDB 的版本支持 TiCDC，否则需要先升级 TiDB 集群至 4.0.0 rc.1 或更新版本。TiCDC 在 4.0.6 版本已经 GA，建议使用 4.0.6 及以后的版本。
 
 2. 参考[扩容 TiDB/TiKV/PD/TiCDC 节点](/scale-tidb-using-tiup.md#扩容-ticdc-节点)章节对 TiCDC 进行部署。
 
-## 使用 binary 在原有 TiDB 集群上新增 TiCDC 组件（不推荐）
+## 手动使用 binary 在现有 TiDB 集群上新增 TiCDC 组件（不推荐）
 
 假设 PD 集群有一个可以提供服务的 PD 节点（client URL 为 `10.0.10.25:2379`）。若要部署三个 TiCDC 节点，可以按照以下命令启动集群。只需要指定相同的 PD 地址，新启动的节点就可以自动加入 TiCDC 集群。
 
@@ -46,6 +55,10 @@ cdc server --cluster-id=default --pd=http://10.0.10.25:2379 --log-file=ticdc_2.l
 cdc server --cluster-id=default --pd=http://10.0.10.25:2379 --log-file=ticdc_3.log --addr=0.0.0.0:8303 --advertise-addr=127.0.0.1:8303
 ```
 
+## 使用加密传输 (TLS) 功能
+
+请参阅[为 TiDB 组件间通信开启加密传输](/enable-tls-between-components.md)。
+
 ## TiCDC `cdc server` 命令行参数说明
 
 对于 `cdc server` 命令中可用选项解释如下：
@@ -64,3 +77,74 @@ cdc server --cluster-id=default --pd=http://10.0.10.25:2379 --log-file=ticdc_3.l
 - `key`：TiCDC 创建 TLS 连接时使用的证书密钥文件路径，PEM 格式，可选。
 - `tz`：TiCDC 服务使用的时区。TiCDC 在内部转换 `TIMESTAMP` 等时间数据类型和向下游同步数据时使用该时区，默认为进程运行本地时区。（注意如果同时指定 `tz` 参数和 `sink-uri` 中的 `time-zone` 参数，TiCDC 进程内部使用 `tz` 指定的时区，sink 向下游执行时使用 `time-zone` 指定的时区）
 - `cluster-id`：TiCDC 集群的 ID。可选，默认值为 `default`。`cluster-id` 是 TiCDC 集群的唯一标识，拥有相同 `cluster-id` 的 TiCDC 节点同属一个集群。长度最大为 128，需要符合正则表达式 `^[a-zA-Z0-9]+(-[a-zA-Z0-9]+)*$`，且不能是以下值：`owner`，`capture`，`task`，`changefeed`，`job`，`meta`。
+
+## 使用 TiUP 运维管理 TiCDC 集群
+
+### 使用 TiUP 升级 TiCDC
+
+使用 TiUP 来升级 TiCDC 集群。在以下例子中，假设需要将 TiCDC 组件和整个 TiDB 集群升级到 v6.3.0。
+
+{{< copyable "shell-regular" >}}
+
+```shell
+tiup update --self && \
+tiup update --all && \
+tiup cluster upgrade <cluster-name> v6.3.0
+```
+
+### TiCDC 滚动升级功能
+
+TiCDC 从 v6.3.0 版本开始在内部实现了支持滚动升级的能力，使用 TiUP 执行对 TiCDC 集群进行滚动升级，扩容 / 缩容操作时，同步延迟保持平稳。该功能要求如下：
+
+* 升级前 TiCDC 版本至少为 v6.3.0，且至少有 2 个正在运行的 TiCDC 实例。
+* TiUP 版本至少为 v1.11.0。
+
+如果上述条件无法满足，将会强制执行相关操作，不保证 TiCDC 集群升级过程中的同步延迟情况。
+
+假设当前版本为 v6.3.0，使用 TiUP 升级集群到 v6.4.0 ：
+
+{{< copyable "shell-regular" >}}
+
+```shell
+tiup cluster upgrade test-cluster v6.4.0 --transfer-timeout 600 --force false
+```
+
+该操作在执行时对每一个 TiCDC 实例依次执行，将正在被升级的 TiCDC 实例上的工作负载表迁移到其他 TiCDC 实例上，然后执行下线节点，升级节点，上线新节点等操作。与之前版本的 TiCDC 升级过程相比，耗时变长，但是在升级过程中同步任务延迟能够被有效控制在一个较小的波动范围内。该功能同样被应用于缩容 TiCDC 节点的场景。
+
+如果用户想要尽快升级 TiCDC 节点，不考虑升级过程中的延迟上升情况，可以传入 `--force=true` 参数。
+
+运维升级 / 缩容一个 TiCDC 节点的耗时，和该节点上当前被分配的表同步任务数量相关，以及被连接的 regions 数量相关。表数量越多，regions 数量也就越多，迁移表耗时越长。TiUP 默认由 `--transfer-timeout` 参数控制该过程的时长，默认为 `600s`。
+
+如果在该时间范围内，TiCDC 节点上的表没能被完全迁移到其他节点上，那么执行强制升级 / 缩容操作，这种情况下不保证同步延迟。你可以根据当前集群中，TiKV 节点上 regions 的数量，TiCDC 节点上同步表的数量，在执行命令时设置修改该参数，保证每个节点滚动升级过程能够在 `transfer-timeout` 时间范围内完成。
+
+在我们的测试过程中，部署 3 个 TiKV 节点，在升级 TiKV 的过程中，每秒平均迁移约 192 个 region leader 到其他 TiKV 节点；部署 2 个 TiCDC 节点，每个节点同步 300 张表，升级 TiCDC 的过程中，每秒平均迁移约 4 张表到其他 TiCDC 节点。
+
+### 升级的注意事项
+
+* TiCDC v4.0.2 对 `changefeed` 的配置做了调整，请参阅[配置文件兼容注意事项](/ticdc/manage-ticdc.md#配置文件兼容性的注意事项)。
+* 升级期间遇到的问题及其解决办法，请参阅[使用 TiUP 升级 TiDB](/upgrade-tidb-using-tiup.md#4-升级-faq)。
+
+## 使用 TiUP 修改 TiCDC 配置
+
+本节介绍如何使用 TiUP 的 [`tiup cluster edit-config`](/tiup/tiup-component-cluster-edit-config.md) 命令来修改 TiCDC 的配置。在以下例子中，假设需要把 TiCDC 的 `gc-ttl` 从默认值 `86400` 修改为 `3600`，即 1 小时。
+
+首先执行以下命令。将 `<cluster-name>` 替换成实际的集群名。
+
+{{< copyable "shell-regular" >}}
+
+```shell
+tiup cluster edit-config <cluster-name>
+```
+
+执行以上命令之后，进入到 vi 编辑器页面，修改 [`server-configs`](/tiup/tiup-cluster-topology-reference.md#server_configs) 下的 `cdc` 配置，如下所示：
+
+```shell
+ server_configs:
+  tidb: {}
+  tikv: {}
+  pd: {}
+  cdc:
+    gc-ttl: 3600
+```
+
+修改完毕后执行 `tiup cluster reload -R cdc` 命令重新加载配置。
diff --git a/ticdc/manage-ticdc.md b/ticdc/manage-ticdc.md
@@ -1,62 +1,12 @@
 ---
-title: TiCDC 运维操作及任务管理
+title: TiCDC 任务管理
 aliases: ['/docs-cn/dev/ticdc/manage-ticdc/','/docs-cn/dev/reference/tools/ticdc/manage/','/docs-cn/dev/reference/tools/ticdc/sink/','/docs-cn/dev/ticdc/sink-url/']
 ---
 
-# TiCDC 运维操作及任务管理
+# TiCDC 任务管理
 
 本文档介绍如何通过 TiCDC 提供的命令行工具 `cdc cli` 管理 TiCDC 集群和同步任务，并介绍了如何使用 TiUP 来升级和修改 TiCDC 集群的配置。你也可以通过 HTTP 接口，即 TiCDC OpenAPI 来管理 TiCDC 集群和同步任务，详见 [TiCDC OpenAPI](/ticdc/ticdc-open-api.md)。
 
-## 使用 TiUP 升级 TiCDC
-
-本部分介绍如何使用 TiUP 来升级 TiCDC 集群。在以下例子中，假设需要将 TiCDC 组件和整个 TiDB 集群升级到 v6.2.0。
-
-{{< copyable "shell-regular" >}}
-
-```shell
-tiup update --self && \
-tiup update --all && \
-tiup cluster upgrade <cluster-name> v6.2.0
-```
-
-### 升级的注意事项
-
-* TiCDC v4.0.2 对 `changefeed` 的配置做了调整，请参阅[配置文件兼容注意事项](/ticdc/manage-ticdc.md#配置文件兼容性的注意事项)。
-* 升级期间遇到的问题及其解决办法，请参阅[使用 TiUP 升级 TiDB](/upgrade-tidb-using-tiup.md#4-升级-faq)。
-
-## 使用 TiUP 修改 TiCDC 配置
-
-本节介绍如何使用 TiUP 的 [`tiup cluster edit-config`](/tiup/tiup-component-cluster-edit-config.md) 命令来修改 TiCDC 的配置。在以下例子中，假设需要把 TiCDC 的 `gc-ttl` 从默认值 `86400` 修改为 `3600`，即 1 小时。
-
-首先执行以下命令。将 `<cluster-name>` 替换成实际的集群名。
-
-{{< copyable "shell-regular" >}}
-
-```shell
-tiup cluster edit-config <cluster-name>
-```
-
-执行以上命令之后，进入到 vi 编辑器页面，修改 [`server-configs`](/tiup/tiup-cluster-topology-reference.md#server_configs) 下的 `cdc` 配置，如下所示：
-
-```shell
- server_configs:
-  tidb: {}
-  tikv: {}
-  pd: {}
-  tiflash: {}
-  tiflash-learner: {}
-  pump: {}
-  drainer: {}
-  cdc:
-    gc-ttl: 3600
-```
-
-修改完毕后执行 `tiup cluster reload -R cdc` 命令重新加载配置。
-
-## 使用加密传输 (TLS) 功能
-
-请参阅[为 TiDB 组件间通信开启加密传输](/enable-tls-between-components.md)。
-
 ## 使用 `cdc cli` 工具来管理集群状态和数据同步
 
 本部分介绍如何使用 `cdc cli` 工具来管理集群状态和数据同步。`cdc cli` 是指通过 `cdc` binary 执行 `cli` 子命令。在以下描述中，通过 `cdc` binary 直接执行 `cli` 命令，TiCDC 的监听 IP 地址为 `10.0.10.25`，端口为 `8300`。

diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md
@@ -64,7 +64,7 @@ cdc cli changefeed list --pd=http://10.0.10.25:2379
 
 在 TiCDC 中启用了这一功能，用来保证 TiCDC 在不可用、或同步任务中断情况下，可以在 TiKV 内保留 TiCDC 需要消费的数据不被 GC 清理掉。
 
-启动 TiCDC server 时可以通过 `gc-ttl` 指定 GC safepoint 的 TTL，也可以[通过 TiUP 修改](/ticdc/manage-ticdc.md#使用-tiup-修改-ticdc-配置) TiCDC 的 `gc-ttl`，默认值为 24 小时。在 TiCDC 中这个值有如下两重含义：
+启动 TiCDC server 时可以通过 `gc-ttl` 指定 GC safepoint 的 TTL，也可以[通过 TiUP 修改](/ticdc/deploy-ticdc.md#使用-tiup-修改-ticdc-配置) TiCDC 的 `gc-ttl`，默认值为 24 小时。在 TiCDC 中这个值有如下两重含义：
 
 - 当 TiCDC 服务全部停止后，由 TiCDC 在 PD 所设置的 GC safepoint 保存的最长时间。
 - TiCDC 中某个同步任务中断或者被手动停止时所能停滞的最长时间，若同步任务停滞时间超过 `gc-ttl` 所设置的值，那么该同步任务就会进入 `failed` 状态，无法被恢复，并且不会继续影响 GC safepoint 的推进。

diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md
@@ -5,7 +5,7 @@ aliases: ['/docs-cn/dev/ticdc/ticdc-overview/','/docs-cn/dev/reference/tools/tic
 
 # TiCDC 简介
 
-[TiCDC](https://github.com/pingcap/tiflow/tree/master/cdc) 是一款 TiDB 增量数据同步工具，通过拉取上游 TiKV 的数据变更日志，TiCDC 可以将数据解析为有序的行级变更数据输出到下游。
+[TiCDC](https://github.com/pingcap/tiflow/tree/master/cdc) 是 TiDB 的 [Changed Data Capture](https://en.wikipedia.org/wiki/Change_data_capture) 工具，它拉取上游 TiKV 的数据变更日志，将数据解析为有序的行级变更数据输出到下游，适用于以 TiDB 为数据源的增量数据同步场景。
 
 ## TiCDC 适用场景
 

diff --git a/tiup/tiup-cluster.md b/tiup/tiup-cluster.md
@@ -370,12 +370,12 @@ Global Flags:
   -y, --yes               跳过所有的确认步骤
 ```
 
-例如，把集群升级到 v6.2.0 的命令为：
+例如，把集群升级到 v6.3.0 的命令为：
 
 {{< copyable "shell-regular" >}}
 
 ```bash
-tiup cluster upgrade tidb-test v6.2.0
+tiup cluster upgrade tidb-test v6.3.0
 ```
 
 ## 更新配置

diff --git a/tiup/tiup-component-cluster-patch.md b/tiup/tiup-component-cluster-patch.md
@@ -37,7 +37,7 @@ tiup cluster patch <cluster-name> <package-path> [flags]
 - 数据类型：`BOOLEAN`
 - 该选项默认关闭，默认值为 `false`。在命令中添加该选项，并传入 `true` 值或不传值，均可开启此功能。
 
-### --transfer-timeout（uint，默认 300）
+### --transfer-timeout（uint，默认 600）
 
 在重启 PD 或 TiKV 时，会先将被重启节点的 leader 迁移到其他节点，迁移过程会需要一定时间，可以通过设置 `--transfer-timeout` 设置最长等待时间（单位为秒），超时之后会跳过等待直接重启服务。
 

diff --git a/tiup/tiup-component-cluster-reload.md b/tiup/tiup-component-cluster-reload.md
@@ -22,7 +22,7 @@ tiup cluster reload <cluster-name> [flags]
 - 数据类型：`BOOLEAN`
 - 该选项默认关闭，默认值为 `false`。在命令中添加该选项，并传入 `true` 值或不传值，均可开启此功能。
 
-### --transfer-timeout（uint，默认 300）
+### --transfer-timeout（uint，默认 600）
 
 在重启 PD 或 TiKV 时，会先将被重启节点的 leader 迁移到其他节点，迁移过程会需要一定时间，可以通过设置 `--transfer-timeout` 设置最长等待时间（单位为秒），超时之后会跳过等待直接重启服务。
 

diff --git a/tiup/tiup-component-cluster-scale-in.md b/tiup/tiup-component-cluster-scale-in.md
@@ -45,7 +45,7 @@ tiup cluster scale-in <cluster-name> [flags]
 >
 > 使用该选项强制移除正在服务和下线中的 TiKV / TiFlash 节点时，这些节点会被直接删除，不等待数据调度完成，因此这个场景下存在较大概率丢失数据的风险。不建议对未宕机的节点使用该选项。
 
-### --transfer-timeout（uint，默认 300）
+### --transfer-timeout（uint，默认 600）
 
 在缩容 PD 或 TiKV 时，会先将被缩容节点的 leader 迁移到其他节点，迁移过程会需要一定时间，可以通过设置 `--transfer-timeout` 设置最长等待时间（单位为秒），超时之后会跳过等待直接缩容服务。
 

diff --git a/tiup/tiup-component-cluster-upgrade.md b/tiup/tiup-component-cluster-upgrade.md
@@ -27,7 +27,7 @@ tiup cluster upgrade <cluster-name> <version> [flags]
 > 
 > 对正在提供服务的集群强制升级可能导致集群服务不可用。对于未启动的集群，升级成功后会自动启动集群。
 
-### --transfer-timeout（uint，默认 300）
+### --transfer-timeout（uint，默认 600）
 
 在升级 PD 或 TiKV 时，会先将被升级节点的 leader 迁移到其他节点，迁移过程会需要一定时间，可以通过设置 `--transfer-timeout` 设置最长等待时间（单位为秒），超时之后会跳过等待直接升级服务。
 

diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md
@@ -176,7 +176,7 @@ tiup cluster upgrade <cluster-name> v6.2.0
 
 > **注意：**
 >
-> - 滚动升级会逐个升级所有的组件。升级 TiKV 期间，会逐个将 TiKV 上的所有 leader 切走再停止该 TiKV 实例。默认超时时间为 5 分钟（300 秒），超时后会直接停止该实例。
+> - 滚动升级会逐个升级所有的组件。升级 TiKV 期间，会逐个将 TiKV 上的所有 leader 切走再停止该 TiKV 实例。默认超时时间为 10 分钟（600 秒），超时后会直接停止该实例。
 > - 使用 `--force` 参数可以在不驱逐 leader 的前提下快速升级集群至新版本，但是该方式会忽略所有升级中的错误，在升级失败后得不到有效提示，请谨慎使用。
 > - 如果希望保持性能稳定，则需要保证 TiKV 上的所有 leader 驱逐完成后再停止该 TiKV 实例，可以指定 `--transfer-timeout` 为一个更大的值，如 `--transfer-timeout 3600`，单位为秒。
 > - 若想将 TiFlash 从 5.3 之前的版本升级到 5.3 及之后的版本，必须进行 TiFlash 的停机升级。参考如下步骤，可以在确保其他组件正常运行的情况下升级 TiFlash：