Update DM 2.0 related doc (pingcap#4324)

* Update ecosystem-tool-user-case.md * Update ecosystem-tool-user-guide.md * Update tidb-troubleshooting-map.md * Update migration-overview.md * Update migrate-from-aurora-mysql-database.md * Update migrate-from-aurora-mysql-database.md * Update ecosystem-tool-user-case.md Co-authored-by: TomShawn <41534398+TomShawn@users.noreply.github.com> Co-authored-by: ti-srebot <66930949+ti-srebot@users.noreply.github.com>
ti-chi-bot · Aug 26, 2020 · 8866050 · 8866050
1 parent d4b1a54
commit 8866050
Show file tree

Hide file tree

Showing 5 changed files with 6 additions and 204 deletions.
diff --git a/ecosystem-tool-user-case.md b/ecosystem-tool-user-case.md
@@ -18,7 +18,7 @@ aliases: ['/docs-cn/dev/ecosystem-tool-user-case/']
 
 ## 从 MySQL/Aurora 迁移数据
 
-当既需要从 MySQL/Aurora 导入全量数据，又需要迁移增量数据时，可使用 [TiDB Data Migration (DM)](https://docs.pingcap.com/zh/tidb-data-migration/v1.0/overview) 完成全量数据和增量数据的迁移。
+当既需要从 MySQL/Aurora 导入全量数据，又需要迁移增量数据时，可使用 [TiDB Data Migration (DM)](https://docs.pingcap.com/zh/tidb-data-migration/v2.0/overview) 完成[全量数据和增量数据的迁移](https://docs.pingcap.com/zh/tidb-data-migration/v2.0/migrate-from-mysql-aurora)。
 
 如果全量数据量较大（TB 级别），则可先使用 [Dumpling](/dumpling-overview.md) 与 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 完成全量数据的迁移，再使用 DM 完成增量数据的迁移。
 

diff --git a/ecosystem-tool-user-guide.md b/ecosystem-tool-user-guide.md
@@ -63,7 +63,7 @@ aliases: ['/docs-cn/dev/ecosystem-tool-user-guide/','/docs-cn/dev/reference/tool
 
 ## 数据迁入
 
-[TiDB Data Migration (DM)](https://docs.pingcap.com/zh/tidb-data-migration/v1.0/overview) 是将 MySQL/MariaDB 数据迁移到 TiDB 的工具，支持全量数据和增量数据的迁移。
+[TiDB Data Migration (DM)](https://docs.pingcap.com/zh/tidb-data-migration/v2.0/overview) 是将 MySQL/MariaDB 数据迁移到 TiDB 的工具，支持全量数据和增量数据的迁移。
 
 基本信息：
 

diff --git a/migrate-from-aurora-mysql-database.md b/migrate-from-aurora-mysql-database.md
@@ -6,202 +6,4 @@ aliases: ['/docs-cn/dev/migrate-from-aurora-mysql-database/','/docs-cn/dev/how-t
 
 # 从 MySQL 迁移数据——以 Amazon Aurora MySQL 为例
 
-本文以 [Amazon Aurora MySQL](https://aws.amazon.com/cn/rds/aurora/details/mysql-details/) 为例介绍如何使用 DM 从 MySQL 协议数据库迁移数据到 TiDB。
-
-## 第 1 步：在 Aurora 集群中启用 binlog
-
-假设有两个 Aurora 集群需要迁移数据到 TiDB，其集群信息如下，其中 Aurora-1 包含一个独立的读取器节点。
-
-| 集群 | 终端节点 | 端口 | 角色 |
-|:-------- |:--- | :--- | :--- |
-| Aurora-1 | pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | 写入器 |
-| Aurora-1 | pingcap-1-us-east-2a.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | 读取器 |
-| Aurora-2 | pingcap-2.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | 写入器 |
-
-DM 在增量同步阶段依赖 `ROW` 格式的 binlog，如果未启用 binlog 及设置正确的 binlog 格式，则不能正常使用 DM 进行数据同步，具体可参见[检查内容](https://docs.pingcap.com/zh/tidb-data-migration/v1.0/precheck#检查内容)。
-
-> **注意：**
->
-> Aurora 读取器不能开启 binlog，因此不能作为 DM 数据迁移时的上游 master server。
-
-如果需要基于 GTID 进行数据迁移，还需要为 Aurora 集群启用 GTID 支持。
-
-> **注意：**
->
-> 基于 GTID 的数据迁移需要 MySQL 5.7 (Aurora 2.04.1) 或更高版本。
-
-### 为 Aurora 集群修改 binlog 相关参数
-
-在 Aurora 集群中，binlog 相关参数是**集群参数组中的集群级参数**，有关如何为 Aurora 集群启用 binlog 支持，请参考[在复制主实例上启用二进制日志记录](https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html#AuroraMySQL.Replication.MySQL.EnableBinlog)。在使用 DM 进行数据迁移时，需要将 `binlog_format` 参数设置为 `ROW`。
-
-如果需要基于 GTID 进行数据迁移，需要将 `gtid-mode` 与 `enforce_gtid_consistency` 均设置为 `ON`。有关如何为 Aurora 集群启用基于 GTID 的数据迁移支持，请参考 [Configuring GTID-Based Replication for an Aurora MySQL Cluster](https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/mysql-replication-gtid.html#mysql-replication-gtid.configuring-aurora)。
-
-> **注意：**
->
-> 在 Aurora 管理后台中，`gtid_mode` 参数表示为 `gtid-mode`。
-
-## 第 2 步：部署 DM 集群
-
-目前推荐使用 DM-Ansible 部署 DM 集群，具体部署方法参照[使用 DM-Ansible 部署 DM 集群](https://docs.pingcap.com/zh/tidb-data-migration/v1.0/deploy-a-dm-cluster-using-ansible)。
-
-> **注意：**
->
-> - 在 DM 所有的配置文件中，数据库的密码要使用 dmctl 加密后的密文。如果数据库密码为空，则不需要加密。关于如何使用 dmctl 加密明文密码，参考[使用 dmctl 加密上游 MySQL 用户密码](https://docs.pingcap.com/zh/tidb-data-migration/v1.0/deploy-a-dm-cluster-using-ansible#使用-dmctl-加密上游-mysql-用户密码)。
-> - 上下游数据库用户必须拥有相应的读写权限。
-
-## 第 3 步：检查集群信息
-
-使用 DM-Ansible 部署 DM 集群后，相关配置信息如下：
-
-- DM 集群相关组件配置信息
-
-    | 组件 | 主机 | 端口 |
-    |:------|:---- |:---- |
-    | dm_worker1 | 172.16.10.72 | 8262 |
-    | dm_worker2 | 172.16.10.73 | 8262 |
-    | dm_master | 172.16.10.71 | 8261 |
-
-- 上下游数据库实例相关信息
-
-    | 数据库实例 | 主机 | 端口 | 用户名 | 加密密码 |
-    |:-------- |:--- | :--- | :--- | :--- |
-    | 上游 Aurora-1 | pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | root | VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU= |
-    | 上游 Aurora-2 | pingcap-2.h8emfqdptyc4.us-east-2.rds.amazonaws.com | 3306 | root | VjX8cEeTX+qcvZ3bPaO4h0C80pe/1aU= |
-    | 下游 TiDB | 172.16.10.83 | 4000 | root | |
-
-- dm-master 进程配置文件 `{ansible deploy}/conf/dm-master.toml` 中的配置
-
-    ```toml
-    # Master 配置。
-
-    [[deploy]]
-    source-id = "mysql-replica-01"
-    dm-worker = "172.16.10.72:8262"
-
-    [[deploy]]
-    source-id = "mysql-replica-02"
-    dm-worker = "172.16.10.73:8262"
-    ```
-
-## 第 4 步：配置任务
-
-假设需要将 Aurora-1 和 Aurora-2 实例的 `test_db` 库的 `test_table` 表以**全量+增量**的模式同步到下游 TiDB 的 `test_db` 库的 `test_table` 表。
-
-复制并编辑 `{ansible deploy}/conf/task.yaml.example`，生成如下任务配置文件 `task.yaml`：
-
-```yaml
-# 任务名，多个同时运行的任务不能重名。
-name: "test"
-# 全量+增量 (all) 同步模式。
-task-mode: "all"
-# 下游 TiDB 配置信息。
-target-database:
-  host: "172.16.10.83"
-  port: 4000
-  user: "root"
-  password: ""
-
-# 当前数据同步任务需要的全部上游 MySQL 实例配置。
-mysql-instances:
--
-  # 上游实例或者复制组 ID，参考 `inventory.ini` 的 `source_id` 或者 `dm-master.toml` 的 `source-id 配置`。
-  source-id: "mysql-replica-01"
-  # 需要同步的库名或表名的黑白名单的配置项名称，用于引用全局的黑白名单配置，全局配置见下面的 `black-white-list` 的配置。
-  black-white-list: "global"
-  # Mydumper 的配置项名称，用于引用全局的 Mydumper 配置。
-  mydumper-config-name: "global"
-
--
-  source-id: "mysql-replica-02"
-  black-white-list: "global"
-  mydumper-config-name: "global"
-
-# 黑白名单全局配置，各实例通过配置项名引用。
-black-white-list:
-  global:
-    do-tables:                        # 需要同步的上游表的白名单。
-    - db-name: "test_db"              # 需要同步的表的库名。
-      tbl-name: "test_table"          # 需要同步的表的名称。
-
-# Mydumper 全局配置，各实例通过配置项名引用。
-mydumpers:
-  global:
-    extra-args: "-B test_db -T test_table"  # mydumper 的其他参数，从 DM 1.0.2 版本开始，DM 会自动生成 table-list 配置，在其之前的版本仍然需要人工配置。
-```
-
-## 第 5 步：启动任务
-
-1. 进入 dmctl 目录 `/home/tidb/dm-ansible/resources/bin/`
-
-2. 执行以下命令启动 dmctl
-
-    {{< copyable "shell-regular" >}}
-
-    ```bash
-    ./dmctl --master-addr 172.16.10.71:8261
-    ```
-
-3. 执行以下命令启动数据同步任务（`task.yaml` 是之前编辑的配置文件）
-
-    {{< copyable "shell-regular" >}}
-
-    ```bash
-    start-task ./task.yaml
-    ```
-
-    - 如果执行命令后的返回结果中不包含错误信息，则表明任务已经成功启动
-    - 如果包含以下错误信息，则表明上游 Aurora 用户可能拥有 TiDB 不支持的权限类型
-
-        ```json
-        {
-            "id": 4,
-            "name": "source db dump privilege chcker",
-            "desc": "check dump privileges of source DB",
-            "state": "fail",
-            "errorMsg": "line 1 column 285 near \"LOAD FROM S3, SELECT INTO S3 ON *.* TO 'root'@'%' WITH GRANT OPTION\" ...",
-            "instruction": "",
-            "extra": "address of db instance - pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com"
-        },
-        {
-            "id": 5,
-            "name": "source db replication privilege chcker",
-            "desc": "check replication privileges of source DB",
-            "state": "fail",
-            "errorMsg": "line 1 column 285 near \"LOAD FROM S3, SELECT INTO S3 ON *.* TO 'root'@'%' WITH GRANT OPTION\" ...",
-            "instruction": "",
-            "extra": "address of db instance - pingcap-1.h8emfqdptyc4.us-east-2.rds.amazonaws.com"
-        }
-        ```
-
-        此时可以选择以下两种处理方法中的任意一种进行处理后，再使用 `start-task` 尝试重新启动任务：
-
-        1. 为用于进行数据迁移的 Aurora 用户移除不被 TiDB 支持的不必要的权限
-        2. 如果能确保 Aurora 用户拥有 DM 所需要的权限，可以在 `task.yaml` 配置文件中添加如下顶级配置项以跳过启用任务时的前置权限检查
-
-            ```yaml
-            ignore-checking-items: ["dump_privilege", "replication_privilege"]
-            ```
-
-## 第 6 步：查询任务
-
-如需了解 DM 集群中是否存在正在运行的同步任务及任务状态等信息，可在 dmctl 内使用以下命令进行查询：
-
-{{< copyable "shell-regular" >}}
-
-```bash
-query-status
-```
-
-> **注意：**
->
-> 如果查询命令的返回结果中包含以下错误信息，则表明在全量同步的 dump 阶段不能获得相应的 lock：
->
-> ```
-> Couldn't acquire global lock, snapshots will not be consistent: Access denied for user 'root'@'%' (using password: YES)
-> ```
->
-> 此时如果能接受不使用 FTWL 来确保 dump 文件与 metadata 的一致或上游能暂时停止写入，可以通过为 `mydumpers` 下的 `extra-args` 添加 `--no-locks` 参数来进行绕过，具体方法为：
->
-> 1. 使用 `stop-task` 停止当前由于不能正常 dump 而已经转为 paused 的任务
-> 2. 将原 `task.yaml` 中的 `extra-args: "-B test_db -T test_table"` 更新为 `extra-args: "-B test_db -T test_table --no-locks"`
-> 3. 使用 `start-task` 重新启动任务
+若要从 MySQL 协议数据库迁移数据到 TiDB，可参阅 DM 文档[从 Aurora 迁移到 TiDB](https://docs.pingcap.com/zh/tidb-data-migration/v2.0/migrate-from-mysql-aurora)。
diff --git a/migration-overview.md b/migration-overview.md
@@ -33,7 +33,7 @@ aliases: ['/docs-cn/dev/migration-overview/','/docs-cn/dev/data-migration-route'
 
 #### 迁移方法
 
-DM 支持将 MySQL 全量数据迁移到 TiDB，并同步 MySQL 的增量数据到 TiDB，详细信息可参考[使用 DM 工具从 Amazon Aurora MySQL 迁移](/migrate-from-aurora-mysql-database.md)
+DM 支持将 MySQL 全量数据迁移到 TiDB，并同步 MySQL 的增量数据到 TiDB，详细信息可参考[使用 DM 工具从 Amazon Aurora MySQL 迁移](https://docs.pingcap.com/zh/tidb-data-migration/v2.0/migrate-from-mysql-aurora)
 
 ## 从文件迁移到 TiDB
 

diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md
@@ -413,9 +413,9 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles
 
 - 6.2.2 执行 `query-status` 或查看日志时出现 `Access denied for user 'root'@'172.31.43.27' (using password: YES)`。
 
-    - 在所有 DM 配置文件中，数据库相关的密码都必须使用经 dmctl 加密后的密文（若数据库密码为空，则无需加密）。
+    - 在所有 DM 配置文件中，数据库相关的密码都必须使用经 dmctl 加密后的密文（若数据库密码为空，则无需加密）。在 v1.0.6 以后的版本可使用明文密码。
 
-    - 在 DM 运行过程中，上下游数据库的用户必须具备相应的读写权限。在启动同步任务过程中，DM 会自动进行[相应权限的检查](https://docs.pingcap.com/zh/tidb-data-migration/v1.0/precheck)。
+    - 在 DM 运行过程中，上下游数据库的用户必须具备相应的读写权限。在启动同步任务过程中，DM 会自动进行[相应权限的检查](https://docs.pingcap.com/zh/tidb-data-migration/v2.0/precheck)。
 
     - 同一套 DM 集群，混合部署不同版本的 DM-worker/DM-master/dmctl，见案例 [AskTUG-1049](https://asktug.com/t/dm1-0-0-ga-access-denied-for-user/1049/5)。