change absolute path to relative path of docs-cn repo files (pingcap#…

…3381)

* change absolute path to relative path of docs-cn repo files

* add aliases for the 3 deleted ticdc files

Co-authored-by: yikeke <yikeke@pingcap.com>

best-practices/tidb-best-practices.md

@@ -181,7 +181,7 @@ TiDB [使用 Grafana + Prometheus 监控系统状态](/tidb-monitoring-framework
 了解一个系统或者解决使用中的问题最好的方法是阅读文档，明白实现原理。TiDB 有大量的官方文档，希望大家在遇到问题的时候能先尝试通过文档或者搜索 Issue list 寻找解决方案。官方文档查看 [docs-cn](https://github.com/pingcap/docs-cn)。如果希望阅读英文文档，可以查看 [docs](https://github.com/pingcap/docs)。
 
 其中的 [FAQ](/faq/tidb-faq.md)
-和[故障诊断](https://pingcap.com/docs-cn/dev/how-to/troubleshoot/cluster-setup/)章节建议大家仔细阅读。另外 TiDB 还有一些不错的工具，也有配套的文档，具体的见各项工具的 GitHub 页面。
+和[故障诊断](/troubleshoot-tidb-cluster.md)章节建议大家仔细阅读。另外 TiDB 还有一些不错的工具，也有配套的文档，具体的见各项工具的 GitHub 页面。
 
 除了文档之外，还有很多不错的文章介绍 TiDB 的各项技术细节内幕，大家可以关注下面这些文章发布渠道：
 

dashboard/dashboard-statement-detail.md

@@ -19,7 +19,7 @@ category: how-to
 执行计划详情包括以下内容：
 
 - SQL 样本：该计划对应的实际执行的某一条 SQL 语句文本。时间范围内任何出现过的 SQL 都可能作为 SQL 样本。
-- 执行计划：执行计划的完整内容，参阅[理解 TiDB 执行计划](https://pingcap.com/docs-cn/dev/query-execution-plan/)文档了解如何解读执行计划。如果选择了多个执行计划，则显示的是其中任意一个。
+- 执行计划：执行计划的完整内容，参阅[理解 TiDB 执行计划](/query-execution-plan.md)文档了解如何解读执行计划。如果选择了多个执行计划，则显示的是其中任意一个。
 - 其他关于该 SQL 的基本信息、执行时间、Coprocessor 读取、事务、慢查询等信息，可点击相应标签页标题切换。
 
 ![执行计划详情](/media/dashboard/dashboard-statement-plans-detail.png)

dashboard/dashboard-statement-list.md

@@ -20,7 +20,7 @@ category: how-to
 
 - 在浏览器中访问 <http://127.0.0.1:2379/dashboard/#/statement>（将 `127.0.0.1:2379` 替换为实际 PD 实例地址和端口）。
 
-SQL 语句分析页面所展示的所有数据都来自于 TiDB Statement 系统表，参见 [Statement Summary Tables](https://pingcap.com/docs-cn/dev/statement-summary-tables) 文档了解该系统表的详细情况。
+SQL 语句分析页面所展示的所有数据都来自于 TiDB Statement 系统表，参见 [Statement Summary Tables](/statement-summary-tables.md) 文档了解该系统表的详细情况。
 
 ### 修改列表过滤条件
 
@@ -55,7 +55,7 @@ SQL 语句分析页面所展示的所有数据都来自于 TiDB Statement 系统
 - 数据收集周期：默认 30 分钟，每次进行 SQL 语句分析的时间长度。SQL 语句分析功能每次对一段时间范围内的所有 SQL 语句进行汇总统计，如果这个时间范围过长，则统计的粒度粗，不利用定位问题；如果太短，则统计的粒度细，方便定位问题，但会导致在相同的数据保留时间内产生更多的记录，产生更多的内存占用。因此需要根据实际情况调整，在需要定位问题时适当地将值调低。
 - 数据保留时间：默认 1 天，统计信息保留的时间，超过这个时间的数据会被从系统表中删除。
 
-参见 [Statement Summary Tables 参数设置](https://pingcap.com/docs-cn/dev/statement-summary-tables/#%E5%8F%82%E6%95%B0%E9%85%8D%E7%BD%AE) 文档了解详细情况。
+参见 [Statement Summary Tables 参数设置](/statement-summary-tables.md#参数配置) 文档了解详细情况。
 
 > **注意：**
 >

faq/sql-faq.md

@@ -65,7 +65,7 @@ DELETE，TRUNCATE 和 DROP 都不会立即释放空间。对于 TRUNCATE 和 DRO
 
 ## 数据删除后查询速度为何会变慢？
 
-大量删除数据后，会有很多无用的 key 存在，影响查询效率。可以尝试开启 [Region Merge](https://pingcap.com/docs-cn/v3.0/best-practices/massive-regions-best-practices/#方法五开启-region-merge) 功能，具体看参考[最佳实践](https://pingcap.com/blog-cn/tidb-best-practice/)中的删除数据部分。
+大量删除数据后，会有很多无用的 key 存在，影响查询效率。可以尝试开启 [Region Merge](/best-practices/massive-regions-best-practices.md#方法五开启-region-merge) 功能，具体看参考[最佳实践](https://pingcap.com/blog-cn/tidb-best-practice/)中的删除数据部分。
 
 ## 对数据做删除操作之后，空间回收比较慢，如何处理？
 

releases/release-2.1.17.md

@@ -53,7 +53,7 @@ TiDB Ansible 版本：2.1.17
 + DDL
     - 为 `tikvSnapshot` 添加逆序扫描接口用于高效地查询 DDL History Job，使用该接口后 `ADMIN SHOW DDL JOBS` 的执行时间有明显降低 [#11789](https://github.com/pingcap/tidb/pull/11789)
     - 改进 `CREATE TABLE ... PRE_SPLIT_REGION` 的语义：当指定 `PRE_SPLIT_REGION = N` 时，将预切分的 Region 个数由 2^(N-1) 改为 2^N [#11797](https://github.com/pingcap/tidb/pull/11797/files)
-    - 根据[线上负载与 Add Index 相互影响测试](https://pingcap.com/docs-cn/dev/benchmark/add-index-with-load)，调小 Add Index 后台工作线程的默认参数以避免对线上负载造成较大影响 [#11875](https://github.com/pingcap/tidb/pull/11875)
+    - 根据[线上负载与 Add Index 相互影响测试](/benchmark/online-workloads-and-add-index-operations.md)，调小 Add Index 后台工作线程的默认参数以避免对线上负载造成较大影响 [#11875](https://github.com/pingcap/tidb/pull/11875)
     - 改进 `SPLIT TABLE` 语法的行为：当使用 `SPLIT TABLE ... REGIONS N` 对 Region 切分时，会生成 N 个数据 Region 和 1 个索引 Region [#11929](https://github.com/pingcap/tidb/pull/11929)
     - 在配置文件中添加 `split-region-max-num` 参数，使得 `SPLIT TABLE` 语法允许的最大 Region 数量可调整，该参数默认值 `10000` [#12080](https://github.com/pingcap/tidb/pull/12080)
     - 修复写 binlog 时，`CREATE TABLE` 语句中 `PRE_SPLIT_REGIONS` 部分没有被注释，导致语句不能被下游 MySQL 解析的问题 [#12121](https://github.com/pingcap/tidb/pull/12121)

releases/release-2.1.18.md

@@ -49,7 +49,7 @@ TiDB Ansible 版本：2.1.18
     - 修复 COM_STMT_FETCH 慢日志时间记录和 MySQL 不一致问题 [#12953](https://github.com/pingcap/tidb/pull/12953)
     - 当遇到写冲突时，在报错信息中添加错误码，以方便对冲突原因进行诊断 [#12878](https://github.com/pingcap/tidb/pull/12878)
 + DDL
-    - 为避免误操作，TiDB 默认不再允许删除列的 `AUTO INCREMENT` 属性，当确实需要删除时，请更改系统变量 `tidb_allow_remove_auto_inc`；相关文档请见：[TiDB 专用系统变量和语法](https://pingcap.com/docs-cn/dev/reference/configuration/tidb-server/tidb-specific-variables/) [#12146](https://github.com/pingcap/tidb/pull/12146)
+    - 为避免误操作，TiDB 默认不再允许删除列的 `AUTO INCREMENT` 属性，当确实需要删除时，请更改系统变量 `tidb_allow_remove_auto_inc`；相关文档请见：[TiDB 专用系统变量和语法](/tidb-specific-system-variables.md) [#12146](https://github.com/pingcap/tidb/pull/12146)
     - 支持 Create Table 语句中建唯一索引时带多个 Unique [#12469](https://github.com/pingcap/tidb/pull/12469)
     - 修复 `CreateTable` 语句中指定外键约束时，外键表在没有指定 Database 时未能使用主表的 Database 导致报错的问题 [#12678](https://github.com/pingcap/tidb/pull/12678)
     - 修复 `ADMIN CANCEL DDL JOBS` 时报 `invalid list index` 错的问题 [#12681](https://github.com/pingcap/tidb/pull/12681)

ticdc-deployment-topology.md

@@ -2,6 +2,7 @@
 title: TiCDC 部署拓扑
 summary: 介绍 TiCDC 部署 TiDB 集群的拓扑结构。
 category: how-to
+aliases: ['/docs-cn/dev/reference/tools/ticdc/deploy/','/docs-cn/dev/ticdc/deploy-ticdc/']
 ---
 
 > **注意：**

ticdc/manage-ticdc.md

@@ -1,7 +1,7 @@
 ---
 title: TiCDC 运维操作及任务管理
 category: reference
-aliases: ['/docs-cn/dev/reference/tools/ticdc/manage/']
+aliases: ['/docs-cn/dev/reference/tools/ticdc/manage/','/docs-cn/dev/reference/tools/ticdc/sink/','/docs-cn/dev/ticdc/sink-url/']
 ---
 
 # TiCDC 运维操作及任务管理

ticdc/ticdc-open-protocol.md

@@ -1,7 +1,7 @@
 ---
 title: TiCDC Open Protocol
 category: reference
-aliases: ['/docs-cn/dev/reference/tools/ticdc/open-protocol/']
+aliases: ['/docs-cn/dev/reference/tools/ticdc/open-protocol/','/docs-cn/dev/ticdc/column-ddl-type-codes/','/docs-cn/stable/reference/tools/ticdc/column-ddl-type/']
 ---
 
 # TiCDC Open Protocol

tidb-best-practices.md

@@ -181,7 +181,7 @@ TiDB [使用 Grafana + Prometheus 监控系统状态](/tidb-monitoring-framework
 了解一个系统或者解决使用中的问题最好的方法是阅读文档，明白实现原理。TiDB 有大量的官方文档，希望大家在遇到问题的时候能先尝试通过文档或者搜索 Issue list 寻找解决方案。官方文档查看 [docs-cn](https://github.com/pingcap/docs-cn)。如果希望阅读英文文档，可以查看 [docs](https://github.com/pingcap/docs)。
 
 其中的 [FAQ](/faq/tidb-faq.md)
-和[故障诊断](https://pingcap.com/docs-cn/dev/how-to/troubleshoot/cluster-setup/)章节建议大家仔细阅读。另外 TiDB 还有一些不错的工具，也有配套的文档，具体的见各项工具的 GitHub 页面。
+和[故障诊断](/troubleshoot-tidb-cluster.md)章节建议大家仔细阅读。另外 TiDB 还有一些不错的工具，也有配套的文档，具体的见各项工具的 GitHub 页面。
 
 除了文档之外，还有很多不错的文章介绍 TiDB 的各项技术细节内幕，大家可以关注下面这些文章发布渠道：
 

tidb-configuration-file.md

@@ -8,7 +8,7 @@ aliases: ['/docs-cn/dev/reference/configuration/tidb-server/configuration-file/'
 
 # TiDB 配置文件描述
 
-TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/config.toml.example](https://github.com/pingcap/tidb/blob/master/config/config.toml.example) 找到默认值的配置文件，重命名为 `config.toml` 即可。本文档只介绍未包含在[命令行参数](https://pingcap.com/docs-cn/dev/reference/configuration/tidb-server/configuration)中的参数。
+TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/config.toml.example](https://github.com/pingcap/tidb/blob/master/config/config.toml.example) 找到默认值的配置文件，重命名为 `config.toml` 即可。本文档只介绍未包含在[命令行参数](/command-line-flags-for-tidb-configuration.md)中的参数。
 
 ### `split-table`
 

tispark-overview.md

@@ -299,7 +299,7 @@ TiSpark 可以使用 TiDB 的统计信息：
 1. 选择代价最低的索引或扫表访问
 2. 估算数据大小以决定是否进行广播优化
 
-如果希望使用统计信息支持，需要确保所涉及的表已经被分析。请阅读[这份文档](https://pingcap.com/docs-cn/dev/reference/performance/statistics/)了解如何进行表分析。
+如果希望使用统计信息支持，需要确保所涉及的表已经被分析。请阅读[这份文档](/statistics.md)了解如何进行表分析。
 
 从 TiSpark 2.0 开始，统计信息将会默认被读取。
 

troubleshoot-hot-spot-issues.md

@@ -86,9 +86,11 @@ TiDB Dashboard 中的「热点可视化」功能可帮助用户缩小热点排
 
 通过设置 SHARD_ROW_ID_BITS，可以把 RowID 打散写入多个不同的 Region，缓解写入热点问题。但是设置的过大会造成 RPC 请求数放大，增加 CPU 和网络开销。
 
+```
 SHARD_ROW_ID_BITS = 4 表示 16 个分片\
 SHARD_ROW_ID_BITS = 6 表示 64 个分片\
 SHARD_ROW_ID_BITS = 0 表示默认值 1 个分片
+```
 
 语句示例：
 
@@ -97,9 +99,9 @@ CREATE TABLE：CREATE TABLE t (c int) SHARD_ROW_ID_BITS = 4;
 ALTER TABLE：ALTER TABLE t SHARD_ROW_ID_BITS = 4;
 ```
 
-> SHARD_ROW_ID_BITS 的值可以动态修改，每次修改之后，只对新写入的数据生效。
->
-> TiDB alter-primary-key 参数设置为 false 时，会使用表的整数型主键作为 RowID，因为 SHARD_ROW_ID_BITS 会改变 RowID 生成规则，所以此时无法使用 SHARD_ROW_ID_BITS 选项。在 alter-primary-key 参数设置为 true 时，TiDB 在建表时不再使用整数型主键作为 RowID，此时带有整数型主键的表也可以使用 SHARD_ROW_ID_BITS 特性。
+SHARD_ROW_ID_BITS 的值可以动态修改，每次修改之后，只对新写入的数据生效。
+
+TiDB alter-primary-key 参数设置为 false 时，会使用表的整数型主键作为 RowID，因为 SHARD_ROW_ID_BITS 会改变 RowID 生成规则，所以此时无法使用 SHARD_ROW_ID_BITS 选项。在 alter-primary-key 参数设置为 true 时，TiDB 在建表时不再使用整数型主键作为 RowID，此时带有整数型主键的表也可以使用 SHARD_ROW_ID_BITS 特性。
 
 以下是两张无主键情况下使用 SHARD_ROW_ID_BITS 打散热点后的流量图，第一张展示了打散前的情况，第二张展示了打散后的情况。
 
@@ -113,10 +115,12 @@ ALTER TABLE：ALTER TABLE t SHARD_ROW_ID_BITS = 4;
 
 使用 AUTO_RANDOM 处理自增主键热点表，适用于代替自增主键，解决自增主键带来的写入热点。
 
+> **注意：**
+>
 > 该功能目前还是实验性功能，不推荐生产环境使用。可使用以下配置启用：
 >
->[experimental]\
->allow-auto-random = true
+> [experimental]\
+> allow-auto-random = true
 
 使用该功能后，将由 TiDB 生成随机分布且空间耗尽前不重复的主键，达到离散写入、打散写入热点的目的。
 
@@ -151,14 +155,15 @@ ALTER TABLE：ALTER TABLE t SHARD_ROW_ID_BITS = 4;
 
 由流量图可见，使用 AUTO_RANDOM 代替 AUTO_INCREMENT 能很好地打散热点。
 
-更详细的说明可以阅读 [AUTO_RANDOM](https://pingcap.com/docs-cn/stable/reference/sql/attributes/auto-random/) 文档。
+更详细的说明可以阅读 [AUTO_RANDOM](/auto-random.md) 文档。
 
 ## 小表热点的优化
 
 TiDB 从 4.0 起支持下推计算结果缓存（即 Coprocessor Cache 功能）。开启该功能后，将在 TiDB 实例侧缓存下推给 TiKV 计算的结果，对于小表读热点能起到比较好的效果。
 
-更详细的说明可以阅读[下推计算结果缓存](https://pingcap.com/docs-cn/stable/coprocessor-cache/#%E9%85%8D%E7%BD%AE)文档
+更详细的说明可以阅读[下推计算结果缓存](/coprocessor-cache.md#配置)文档
+
+**其他相关资料**：
 
-**其他相关资料**\
-[TiDB 高并发写入场景最佳实践](https://pingcap.com/docs-cn/dev/reference/best-practices/high-concurrency/)\
-[Split Region 使用文档](https://pingcap.com/docs-cn/stable/reference/sql/statements/split-region/#split-region-%E4%BD%BF%E7%94%A8%E6%96%87%E6%A1%A3)
++ [TiDB 高并发写入场景最佳实践](/best-practices/high-concurrency-best-practices.md)
++ [Split Region 使用文档](/sql-statements/sql-statement-split-region.md)

upgrade-tidb-using-tiup.md

@@ -208,6 +208,6 @@ TiFlash 在 `v4.0.0-rc.2` 之前的版本可能有一些不兼容的问题。因
 - 4.0 版本增加了 `rename` 时对表名长度的检查，长度限制为 `64` 个字符。升级后 `rename` 后的表名长度超过这个限制会报错，3.0 及之前的版本则不会报错。
 - 4.0 版本增加了对分区表的分区名长度的检查，长度限制为 `64` 个字符。升级后 `create table` 和 `alter table` 分区表时当分区名长度超过这个限制会报错，3.0 及之前的版本则不会报错。
 - 4.0 版本对 `explain` 执行计划的输出格式做了改进，需要注意是否有针对 `explain` 制订了自动化的分析程序。
-- 4.0 版本支持 [Read Committed 隔离级别](https://pingcap.com/docs-cn/stable/transaction-isolation-levels/#读已提交隔离级别-read-committed)。升级到 4.0 后，在悲观事务里隔离级别设置为 `READ-COMMITTED` 会生效，3.0 及之前的版本则不会生效。
+- 4.0 版本支持 [Read Committed 隔离级别](/transaction-isolation-levels.md#读已提交隔离级别-read-committed)。升级到 4.0 后，在悲观事务里隔离级别设置为 `READ-COMMITTED` 会生效，3.0 及之前的版本则不会生效。
 - 4.0 版本执行 `alter reorganize partition` 会报错，之前的版本则不会报错，只是语法上支持没有实际效果。
 - 4.0 版本创建 `linear hash partition` 和 `subpartition` 分区表时实际不生效，会转换为普通表，之前的版本则转换为普通分区表。