pingcap · ti-chi-bot · Nov 13, 2023 · Oct 26, 2023 · Nov 6, 2023
diff --git a/binary-package.md b/binary-package.md
@@ -40,7 +40,6 @@ TiDB 提供了 amd64 和 arm64 两种架构的离线包。对于每种架构，T
 
 | 内容 | 变更说明 |
 |---|---|
-| tikv-importer-{version}-linux-{arch}.tar.gz |  |
 | pd-recover-{version}-linux-{arch}.tar.gz |  |
 | etcdctl | 从 v6.0.0 起新增 |
 | tiup-linux-{arch}.tar.gz |  |
@@ -67,7 +66,6 @@ TiDB 提供了 amd64 和 arm64 两种架构的离线包。对于每种架构，T
 | sync_diff_inspector |  |
 | reparo |  |
 | arbiter |  |
-| mydumper | 从 v6.0.0 起新增 |
 | server-{version}-linux-{arch}.tar.gz | 从 v6.2.0 起新增 |
 | grafana-{version}-linux-{arch}.tar.gz | 从 v6.2.0 起新增 |
 | alertmanager-{version}-linux-{arch}.tar.gz | 从 v6.2.0 起新增 |

diff --git a/develop/dev-guide-timeouts-in-tidb.md b/develop/dev-guide-timeouts-in-tidb.md
@@ -14,7 +14,7 @@ TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新
 
 默认配置下 TiDB 可以保障每个 MVCC 版本（一致性快照）保存 10 分钟，读取时间超过 10 分钟的事务，会收到报错 `GC life time is shorter than transaction duration`。
 
-当用户确信自己需要更长的读取时间时，比如在使用了 Mydumper 做全量备份的场景中（Mydumper 备份的是一致性的快照），可以通过调整 TiDB 中`mysql.tidb` 表中的 `tikv_gc_life_time` 的值来调大 MVCC 版本保留时间，需要注意的是 tikv_gc_life_time 的配置是立刻影响全局的，调大它会为当前所有存在的快照增加生命时长，调小它会立即缩短所有快照的生命时长。过多的 MVCC 版本会拖慢 TiKV 的处理效率，在使用 Mydumper 做完全量备份后需要及时把 tikv_gc_life_time 调整回之前的设置。
+当用户确信自己需要更长的读取时间时，比如在使用了 Dumpling 做全量备份的场景中（当 Dumpling 备份的是一致性的快照），可以通过调整 TiDB 中`mysql.tidb` 表中的 `tikv_gc_life_time` 的值来调大 MVCC 版本保留时间，需要注意的是 tikv_gc_life_time 的配置是立刻影响全局的，调大它会为当前所有存在的快照增加生命时长，调小它会立即缩短所有快照的生命时长。过多的 MVCC 版本会拖慢 TiKV 的处理效率，在使用 Dumpling 做完全量备份后需要及时把 `tikv_gc_life_time` 调整回之前的设置。
 
 更多关于 GC 的信息，请参考 [GC 机制简介](https://pingcap.com/docs-cn/stable/reference/garbage-collection/overview/)文档。
 

diff --git a/dumpling-overview.md b/dumpling-overview.md
@@ -29,9 +29,9 @@ TiDB 还提供了其他工具，你可以根据需要选择使用：
 
 > **注意：**
 >
-> PingCAP 之前维护的 Mydumper 工具 fork 自 [mydumper project](https://github.com/maxbube/mydumper)，针对 TiDB 的特性进行了优化。关于 Mydumper 的更多信息，请参考 [v4.0 版 Mydumper 使用文档](https://docs.pingcap.com/zh/tidb/v4.0/mydumper-overview)。Mydumper 目前已经不再开发新功能，其绝大部分功能已经被 [Dumpling](/dumpling-overview.md) 取代，请切换到 Dumpling。
+> PingCAP 之前维护的 Mydumper 工具 fork 自 [mydumper project](https://github.com/maxbube/mydumper)，针对 TiDB 的特性进行了优化。从 v7.5.0 开始，[Mydumper](https://docs.pingcap.com/tidb/v4.0/mydumper-overview) 废弃，其绝大部分功能已经被 [Dumpling](/dumpling-overview.md) 取代，强烈建议切换到 Dumpling。
 
-相比 Mydumper，Dumpling 做了如下改进：
+Dumpling 具有以下优势：
 
 - 支持导出多种数据形式，包括 SQL/CSV。
 - 支持全新的 [table-filter](https://github.com/pingcap/tidb-tools/blob/master/pkg/table-filter/README.md)，筛选数据更加方便。

diff --git a/ecosystem-tool-user-guide.md b/ecosystem-tool-user-guide.md
@@ -88,7 +88,7 @@ TiUniManager 不仅提供对 TiDB 集群的全生命周期的可视化管理，
 
 > **注意：**
 >
-> PingCAP 之前维护的 Mydumper 工具 fork 自 [Mydumper project](https://github.com/maxbube/mydumper)，针对 TiDB 的特性进行了优化。Mydumper 已经被 [Dumpling](/dumpling-overview.md) 工具取代，并使用 Go 语言编写，支持更多针对 TiDB 特性的优化。建议切换到 Dumpling。
+> PingCAP 之前维护的 Mydumper 工具 fork 自 [mydumper project](https://github.com/maxbube/mydumper)，针对 TiDB 的特性进行了优化。从 v7.5.0 开始，[Mydumper](https://docs.pingcap.com/tidb/v4.0/mydumper-overview) 废弃，其绝大部分功能已经被 [Dumpling](/dumpling-overview.md) 取代，强烈建议切换到 Dumpling。
 
 ### 全量导入 - TiDB Lightning
 

diff --git a/migration-overview.md b/migration-overview.md
@@ -8,8 +8,8 @@ summary: 了解各种数据迁移场景和对应的数据迁移方案。
 本文档总体介绍可用于 TiDB 的数据迁移方案。数据迁移方案如下：
 
 - 全量数据迁移。
-    - 数据导入：使用 TiDB Lightning 将 Aurora Snapshot，CSV 文件或 Mydumper SQL 文件的数据全量导入到 TiDB 集群。
-    - 数据导出：使用 Dumpling 将 TiDB 集群的数据全量导出为 CSV 文件或 Mydumper SQL 文件，从而更好地配合从 MySQL 数据库或 MariaDB 数据库进行数据迁移。
+    - 数据导入：使用 TiDB Lightning 将 Aurora Snapshot，CSV 文件或 SQL dump 文件的数据全量导入到 TiDB 集群。
+    - 数据导出：使用 Dumpling 将 TiDB 集群的数据全量导出为 CSV 文件或 SQL dump 文件，从而更好地配合从 MySQL 数据库或 MariaDB 数据库进行数据迁移。
     - TiDB DM (Data migration) 也提供了适合小规模数据量数据库（例如小于 1 TiB）的全量数据迁移功能。
 
 - 快速初始化 TiDB 集群：TiDB Lightning 提供的快速导入功能可以实现快速初始化 TiDB 集群的指定表的效果。请注意，使用快速初始化 TiDB 集群的功能对 TiDB 集群的影响极大，在进行初始化的过程中，TiDB 集群不支持对外访问。

diff --git a/tidb-lightning/monitor-tidb-lightning.md b/tidb-lightning/monitor-tidb-lightning.md
@@ -23,26 +23,16 @@ pprof-port = 8289
 ...
 ```
 
-监控的端口也可在 `tikv-importer.toml` 配置：
-
-```toml
-# 状态服务器的监听地址
-status-server-address = '0.0.0.0:8286'
-```
-
 配置 Prometheus 后，`tidb-lightning` 才能发现服务器。配置方法如下，将服务器地址直接添加至 `scrape_configs` 部分：
 
 {{< copyable "" >}}
 
 ```yaml
 ...
 scrape_configs:
-  - job_name: 'lightning'
+  - job_name: 'tidb-lightning'
     static_configs:
       - targets: ['192.168.20.10:8289']
-  - job_name: 'tikv-importer'
-    static_configs:
-      - targets: ['192.168.20.9:8286']
 ```
 
 ## Grafana 面板
@@ -137,88 +127,7 @@ scrape_configs:
 
 ## 监控指标
 
-本节将详细描述 `tikv-importer` 和 `tidb-lightning` 的监控指标。
-
-### `tikv-importer`
-
-`tikv-importer` 的监控指标皆以 `tikv_import_*` 为前缀。
-
-- **`tikv_import_rpc_duration`**（直方图）
-
-    完成一次 RPC 用时直方图。标签：
-
-    - **request**：所执行 RPC 请求的类型
-        * `switch_mode` — 将一个 TiKV 节点切换为 import/normal 模式
-        * `open_engine` — 打开引擎文件
-        * `write_engine` — 接收数据并写入引擎文件
-        * `close_engine` — 关闭一个引擎文件
-        * `import_engine` — 导入一个引擎文件到 TiKV 集群中
-        * `cleanup_engine` — 删除一个引擎文件
-        * `compact_cluster` — 显式压缩 TiKV 集群
-        * `upload` — 上传一个 SST 文件
-        * `ingest` — Ingest 一个 SST 文件
-        * `compact` — 显式压缩一个 TiKV 节点
-    - **result**：RPC 请求的执行结果
-        * `ok`
-        * `error`
-
-- **`tikv_import_write_chunk_bytes`**（直方图）
-
-    从 TiDB Lightning 接收的键值对区块大小（未压缩）的直方图。
-
-- **`tikv_import_write_chunk_duration`**（直方图）
-
-    从 `tidb-lightning` 接收每个键值对区块所需时间的直方图。
-
-- **`tikv_import_upload_chunk_bytes`**（直方图）
-
-    上传到 TiKV 的每个 SST 文件区块大小（压缩）的直方图。
-
-- **`tikv_import_range_delivery_duration`**（直方图）
-
-    将一个 range 的键值对发送至 `dispatch-job` 任务所需时间的直方图。
-
-- **`tikv_import_split_sst_duration`**（直方图）
-
-    将 range 从引擎文件中分离到单个 SST 文件中所需时间的直方图。
-
-- **`tikv_import_sst_delivery_duration`**（直方图）
-
-    将 SST 文件从 `dispatch-job` 任务发送到 `ImportSSTJob` 任务所需时间的直方图
-
-- **`tikv_import_sst_recv_duration`**（直方图）
-
-    `ImportSSTJob` 任务接收从 `dispatch-job` 任务发送过来的 SST 文件所需时间的直方图。
-
-- **`tikv_import_sst_upload_duration`**（直方图）
-
-    从 `ImportSSTJob` 任务上传 SST 文件到 TiKV 节点所需时间的直方图。
-
-- **`tikv_import_sst_chunk_bytes`**（直方图）
-
-    上传到 TiKV 节点的 SST 文件（压缩）大小的直方图。
-
-- **`tikv_import_sst_ingest_duration`**（直方图）
-
-    将 SST 文件传入至 TiKV 所需时间的直方图。
-
-- **`tikv_import_each_phase`**（测量仪）
-
-    表示运行阶段。值为 1 时表示在阶段内运行，值为 0 时表示在阶段内运行。标签：
-
-    - **phase**：`prepare` / `import`
-
-- **`tikv_import_wait_store_available_count`**（计数器）
-
-    计算出现 TiKV 节点没有充足空间上传 SST 文件现象的次数。标签：
-
-    - **store_id**： TiKV 存储 ID。
-
-- **`tikv_import_upload_chunk_duration`**（直方图）
-
-    上传到 TiKV 的每个区块所需时间的直方图。
-
-### `tidb-lightning`
+本节将详细描述 `tidb-lightning` 的监控指标。
 
 `tidb-lightning` 的监控指标皆以 `lightning_*` 为前缀。
 

diff --git a/tidb-lightning/tidb-lightning-command-line-full.md b/tidb-lightning/tidb-lightning-command-line-full.md
@@ -23,7 +23,6 @@ summary: 使用命令行配置 TiDB Lightning。
 | --backend [*backend*](/tidb-lightning/tidb-lightning-overview.md) | 选择导入的模式：`local` 为[物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md)，`tidb` 为[逻辑导入模式](/tidb-lightning/tidb-lightning-logical-import-mode.md) | `tikv-importer.backend` |
 | --log-file *file* | 日志文件路径（默认值为 `/tmp/lightning.log.{timestamp}`，设置为 '-' 表示日志输出到终端） | `lightning.log-file` |
 | --status-addr *ip:port* | TiDB Lightning 服务器的监听地址 | `lightning.status-port` |
-| --importer *host:port* | TiKV Importer 的地址 | `tikv-importer.addr` |
 | --pd-urls *host:port* | PD endpoint 的地址 | `tidb.pd-addr` |
 | --tidb-host *host* | TiDB Server 的 host | `tidb.host` |
 | --tidb-port *port* | TiDB Server 的端口（默认为 4000） | `tidb.port` |

diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md
@@ -49,9 +49,7 @@ enable-diagnose-logs = false
 
 # 引擎文件的最大并行数。
 # 每张表被切分成一个用于存储索引的“索引引擎”和若干存储行数据的“数据引擎”。
-# 这两项设置控制两种引擎文件的最大并发数。
-# 这两项设置的值会影响 tikv-importer 的内存和磁盘用量。
-# 两项数值之和不能超过 tikv-importer 的 max-open-engines 的设定。
+# 这两项设置控制两种引擎文件的最大并发数。通常情况下，你可以使用默认值。
 index-concurrency = 2
 table-concurrency = 6
 
@@ -401,7 +399,6 @@ log-progress = "5m"
 | --backend [*backend*](/tidb-lightning/tidb-lightning-overview.md) | 选择导入的模式：`local` 为物理导入模式，`tidb` 为逻辑导入模式  | `local` |
 | --log-file *file* | 日志文件路径（默认值为 `/tmp/lightning.log.{timestamp}`，设置为 '-' 表示日志输出到终端） | `lightning.log-file` |
 | --status-addr *ip:port* | TiDB Lightning 服务器的监听地址 | `lightning.status-port` |
-| --importer *host:port* | TiKV Importer 的地址 | `tikv-importer.addr` |
 | --pd-urls *host:port* | PD endpoint 的地址 | `tidb.pd-addr` |
 | --tidb-host *host* | TiDB Server 的 host | `tidb.host` |
 | --tidb-port *port* | TiDB Server 的端口（默认为 4000） | `tidb.port` |

diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md
@@ -25,27 +25,8 @@ TiDB Lightning 的版本应与集群相同。如果使用 Local-backend 模式
 
 ## 如何正确重启 TiDB Lightning？
 
-如果使用 Importer-backend，根据 `tikv-importer` 的状态，重启 TiDB Lightning 的基本顺序如下：
-
-如果 `tikv-importer` 仍在运行：
-
-1. [结束 `tidb-lightning` 进程](#如何正确结束-tidb-lightning-进程)。
-2. 执行修改操作（如修复数据源、更改设置、更换硬件等）。
-3. 如果上面的修改操作更改了任何表，你还需要[清除对应的断点](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-remove)。
-4. 重启 `tidb-lightning`。
-
-如果 `tikv-importer` 需要重启：
-
 1. [结束 `tidb-lightning` 进程](#如何正确结束-tidb-lightning-进程)。
-2. [结束 `tikv-importer` 进程](#如何正确结束-tikv-importer-进程)。
-3. 执行修改操作（如修复数据源、更改设置、更换硬件等）。
-4. 重启 `tikv-importer`。
-5. 重启 `tidb-lightning` 并等待，**直到程序因校验和错误（如果有的话）而失败**。
-    * 重启 `tikv-importer` 将清除所有仍在写入的引擎文件，但是 `tidb-lightning` 并不会感知到该操作。从 v3.0 开始，最简单的方法是让 `tidb-lightning` 继续，然后再重试。
-6. [清除失败的表及断点](/tidb-lightning/troubleshoot-tidb-lightning.md#checkpoint-for--has-invalid-status错误码)。
-7. 再次重启 `tidb-lightning`。
-
-如果使用 Local-backend 和 TiDB-backend，操作和 Importer-backend 的 `tikv-importer` 仍在运行时相同。
+2. 启动一个新的 `tidb-lightning` 任务：执行之前的启动命令，例如 `nohup tiup tidb-lightning -config tidb-lightning.toml`。
 
 ## 如何校验导入的数据的正确性？
 
@@ -94,14 +75,6 @@ sql-mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
 ...
 ```
 
-## 可以启用一个 `tikv-importer`，同时有多个 `tidb-lightning` 进程导入数据吗？
-
-只要每个 TiDB Lightning 操作的表互不相同就可以。
-
-## 如何正确结束 `tikv-importer` 进程？
-
-手动部署：如果 `tikv-importer` 正在前台运行，可直接按 <kbd>Ctrl</kbd>+<kbd>C</kbd> 退出。否则，可通过 `ps aux | grep tikv-importer` 获取进程 ID，然后通过 `kill «pid»` 结束进程。
-
 ## 如何正确结束 `tidb-lightning` 进程？
 
 根据部署方式，选择相应操作结束进程。
@@ -121,10 +94,6 @@ sql-mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
 - 索引会占据额外的空间
 - RocksDB 的空间放大效应
 
-## TiDB Lightning 使用过程中是否可以重启 TiKV Importer？
-
-不能，TiKV Importer 会在内存中存储一些引擎文件，重启后，`tidb-lightning` 会因连接失败而停止。此时，你需要[清除失败的断点](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-error-destroy)，因为这些 TiKV Importer 特有的信息丢失了。你可以在之后[重启 TiDB Lightning](#如何正确重启-tidb-lightning)。
-
 ## 如何清除所有与 TiDB Lightning 相关的中间数据？
 
 1. 删除断点文件。
@@ -137,7 +106,7 @@ sql-mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
 
     如果出于某些原因而无法运行该命令，你可以尝试手动删除 `/tmp/tidb_lightning_checkpoint.pb` 文件。
 
-2. 如果使用 Local-backend，删除配置中 `sorted-kv-dir` 对应的目录；如果使用 Importer-backend，删除 `tikv-importer` 所在机器上的整个 `import` 文件目录。
+2. 如果使用 Local-backend，删除配置中 `sorted-kv-dir` 对应的目录。
 
 3. 如果需要的话，删除 TiDB 集群上创建的所有表和库。
 

diff --git a/tidb-lightning/tidb-lightning-physical-import-mode.md b/tidb-lightning/tidb-lightning-physical-import-mode.md
@@ -67,7 +67,6 @@ backend = "local"
 
 - TiDB Lightning 版本 ≥ 4.0.3。
 - TiDB 集群版本 ≥ v4.0.0。
-- 如果目标 TiDB 集群是 v3.x 或以下的版本，需要使用 Importer-backend 来完成数据的导入。在这个模式下，`tidb-lightning` 需要将解析的键值对通过 gRPC 发送给 `tikv-importer` 并由 `tikv-importer` 完成数据的导入。
 
 ### 使用限制
 

diff --git a/tidb-lightning/troubleshoot-tidb-lightning.md b/tidb-lightning/troubleshoot-tidb-lightning.md
@@ -121,26 +121,6 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=
 
 其他解决方法请参考[断点续传的控制](/tidb-lightning/tidb-lightning-checkpoints.md#断点续传的控制)。
 
-### `ResourceTemporarilyUnavailable("Too many open engines …: …")`
-
-**原因**：并行打开的引擎文件 (engine files) 超出 `tikv-importer` 里的限制。这可能由配置错误引起。即使配置没问题，如果 `tidb-lightning` 曾经异常退出，也有可能令引擎文件残留在打开的状态，占据可用的数量。
-
-**解决办法**：
-
-1. 提高 `tikv-importer.toml` 内 `max-open-engines` 的值。这个设置主要由内存决定，计算公式为：
-
-    最大内存使用量 ≈ `max-open-engines` × `write-buffer-size` × `max-write-buffer-number`
-
-2. 降低 `table-concurrency` + `index-concurrency`，使之低于 `max-open-engines`。
-
-3. 重启 `tikv-importer` 来强制移除所有引擎文件 (默认值为 `./data.import/`)。这样也会丢弃导入了一半的表，所以启动 TiDB Lightning 前必须清除过期的断点记录：
-
-    {{< copyable "shell-regular" >}}
-
-    ```sh
-    tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=all
-    ```
-
 ### `cannot guess encoding for input file, please convert to UTF-8 manually`
 
 **原因**：TiDB Lightning 只支持 UTF-8 和 GB-18030 编码的表架构。此错误代表数据源不是这里任一个编码。也有可能是文件中混合了不同的编码，例如，因为在不同的环境运行过 `ALTER TABLE`，使表架构同时出现 UTF-8 和 GB-18030 的字符。
@@ -169,9 +149,7 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=
         TZ='Asia/Shanghai' bin/tidb-lightning -config tidb-lightning.toml
         ```
 
-2. 导出数据时，必须加上 `--skip-tz-utc` 选项。
-
-3. 确保整个集群使用的是同一最新版本的 `tzdata` (2018i 或更高版本)。
+2. 确保整个集群使用的是同一最新版本的 `tzdata` (2018i 或更高版本)。
 
     如果你使用的是 CentOS 机器，你可以运行 `yum info tzdata` 命令查看 `tzdata` 的版本及是否有更新。然后运行 `yum upgrade tzdata` 命令升级 `tzdata`。