ambiguous words: clarify tools words (pingcap#9775)

br/backup-and-restore-use-cases.md

@@ -72,7 +72,7 @@ BR 可以直接将命令下发到 TiKV 集群来执行备份和恢复，不依
 运行 [`br backup`](/br/use-br-command-line-tool.md#br-命令行描述) 命令进行备份前，请确保以下条件：
 
 1. TiDB 集群中没有正在运行中的 DDL。
-2. 用于创建备份的存储设备有足够的空间。
+2. 用于创建备份的存储设备有足够的空间（具有备份集群的 1/3 的磁盘空间即可）。
 
 #### 恢复前的准备工作
 

dm/deploy-a-dm-cluster-using-tiup.md

@@ -16,7 +16,7 @@ aliases: ['/docs-cn/tidb-data-migration/dev/deploy-a-dm-cluster-using-ansible/']
 
 ## 前提条件
 
-当 DM 执行全量数据复制任务时，每个 DM-worker 只绑定一个上游数据库。DM-worker 首先在上游导出全部数据，然后将数据导入下游数据库。因此，DM-worker 的主机需要有足够的存储空间，具体存储路径在后续创建迁移任务时指定。
+当 DM 执行全量数据复制任务时，每个 DM-worker 只绑定一个上游数据库。DM-worker 首先在上游导出全部数据，然后将数据导入下游数据库。因此，DM-worker 的主机空间需要容纳所有要导出的上游表，具体存储路径在后续创建迁移任务时指定。
 
 另外，部署 DM 集群需参照 [DM 集群软硬件环境需求](/dm/dm-hardware-and-software-requirements.md)，满足相应要求。
 

migrate-large-mysql-to-tidb.md

@@ -25,7 +25,7 @@ summary: 介绍如何从大数据量 MySQL 迁移数据到 TiDB。
 
 **磁盘空间**：
 
-- Dumpling 需要足够储存整个数据源的存储空间。
+- Dumpling 需要能够储存整个数据源的存储空间，即可以容纳要导出的所有上游表的空间。计算方式参考[下游数据库所需空间](/tidb-lightning/tidb-lightning-requirements.md#下游数据库所需空间)。
 - TiDB Lightning 导入期间，需要临时空间来存储排序键值对，磁盘空间需要至少能存储数据源的最大单表。
 - 若全量数据量较大，可适当加长上游 binlog 保存时间，以避免增量同步时缺必要 binlog 导致重做。
 
@@ -75,7 +75,7 @@ SELECT table_name,table_schema,SUM(data_length)/1024/1024 AS data_length,SUM(ind
     |-B 或 --database  | 导出指定数据库 |
     |-f 或 --filter | 导出能匹配模式的表，语法可参考 [table-filter](/table-filter.md)。|
 
-    请确保 `${data-path}` 拥有足够的空间。强烈建议使用 `-F` 参数以避免单表过大导致备份过程中断。
+    请确保 `${data-path}` 的空间可以容纳要导出的所有上游表，计算方式参考[下游数据库所需空间](/tidb-lightning/tidb-lightning-requirements.md#下游数据库所需空间)。强烈建议使用 `-F` 参数以避免单表过大导致备份过程中断。
 
 2. 查看在 `${data-path}` 目录下的 `metadata` 文件，这是 Dumpling 自动生成的元信息文件，请记录其中的 binlog 位置信息，这将在第 3 步增量同步的时候使用。
 

tidb-lightning/tidb-lightning-distributed-import.md

@@ -134,7 +134,7 @@ nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out &
 
 在并行导入的场景下，TiDB Lightning 在启动任务之后，会自动进行下列检查：
 
-- 检查本地盘空间以及 TiKV 集群是否有足够空间导入数据。检查时会对数据源进行采样，通过采样结果预估索引大小占比。由于估算中考虑了索引，因此可能会出现尽管数据源大小低于本地盘可用空间，但依然无法通过检测的情况。
+- 检查本地盘空间（即 `sort-kv-dir` 配置）以及 TiKV 集群是否有足够空间导入数据，空间大小的详细说明参考 [TiDB Lightning 下游数据库所需空间](/tidb-lightning/tidb-lightning-requirements.md#下游数据库所需空间)和 [TiDB Lightning 运行时资源要求](/tidb-lightning/tidb-lightning-requirements.md#tidb-lightning-运行时资源要求)。检查时会对数据源进行采样，通过采样结果预估索引大小占比。由于估算中考虑了索引，因此可能会出现尽管数据源大小低于本地盘可用空间，但依然无法通过检测的情况。
 - 检查 TiKV 集群的 region 分布是否均匀，以及是否存在大量空 region，如果空 region 的数量大于 max(1000,  表的数量 * 3) ，即大于 “1000” 和 “3 倍表数量”二者中的最大者，则无法执行导入。
 - 检查数据源导入数据是否有序，并且根据检查结果自动调整 `mydumper.batch-size` 的大小。因此 `mydumper.batch-size` 配置不再对用户开放。
 

tidb-lightning/tidb-lightning-prechecks.md

@@ -13,7 +13,7 @@ summary: 本文档介绍了 TiDB Lightning 前置检查功能，确保 TiDB Ligh
 |  ----  |  --- | ----  |
 | 集群版本/状态是否正常| >= 5.3.0 | 检查配置中集群是否可以连接，当后端模式是 Local 的时候，还会检查 TiKV/PD/TiFlash 版本是否支持 Local 导入模式。|
 | 是否有权限读取数据 | >= 5.3.0 | 检查当从云存储（Amazon S3）读取数据的时候，是否有对应的权限，确保不会因权限缺失导致导入中断。|
-| 导入空间是否足够 | >= 5.3.0 | 检查 TiKV 集群是否有足够空间导入数据。检查时会对数据源进行采样，通过采样结果预估索引大小占比。由于估算中考虑了索引，因此可能会出现尽管数据源大小低于本地盘可用空间，但依然无法通过检测的情况。当后端是 Local 的时候，因为需要在本地进行外部排序，所以还会检查本地存储是否足够。| 
+| 导入空间是否足够 | >= 5.3.0 | 检查 TiKV 集群是否有足够空间导入数据。检查时会对数据源进行采样，通过采样结果预估索引大小占比。由于估算中考虑了索引，因此可能会出现尽管数据源大小低于本地盘可用空间，但依然无法通过检测的情况。当后端是 Local 的时候，因为需要在本地进行外部排序，所以还会检查本地存储是否足够。有关 TiKV 集群空间和本地存储（即 `sort-kv-dir` 配置）空间大小的详细说明，参考 [TiDB Lightning 下游数据库所需空间](/tidb-lightning/tidb-lightning-requirements.md#下游数据库所需空间)和 [TiDB Lightning 运行时资源要求](/tidb-lightning/tidb-lightning-requirements.md#tidb-lightning-运行时资源要求)| 
 | Region 分布状态 | >= 5.3.0 | 检查 TiKV 集群的 Region 分布是否均匀，以及是否存在大量空 region，如果空 Region 的数量大于 `max(1000,  表的数量 * 3)`，即大于 "1000" 和 "3 倍表数量"二者中的较大者，TiDB Lightning 无法执行导入。 |
 | 数据文件是否有大 CSV 文件 | >= 5.3.0 | 当备份文件中出现大于 10 GiB 的 CSV 文件且无法进行自动切分 (StrictFormat=false) 的时候，会导致导入性能下降。该检查的目的是提醒用户确保数据格式的情况下，开启自动切分 CSV 功能。 |
 | 是否可以从断点恢复 | >= 5.3.0 | 该检查是确保断点恢复过程中，不会出现对源文件和数据库中 schema 进行修改，导致导入错误数据的情况。|